The equality test seems to have a bug.

p:Integer->Integer

Type: Void

p(x)==x

Type: Void

p

(1)

Type: FunctionCalled(p)

t:Boolean:=(p=p)

Compiling function p with type Integer -> Integer

(2)

Type: Boolean

)set mess bot on

t:=(p=p)

 Function Selection for =
      Arguments: ((INT -> INT),(INT -> INT))
      Target type: BOOLEAN 

 [1]  signature:   ((INT -> INT),(INT -> INT)) -> BOOLEAN
      implemented: slot (Boolean)$$ from (INT -> INT)

(3)

Type: Boolean

In fact, in variable.spad, the result should be true always.

So the code has no bugs! The Interpreter uses the wrong equality test function. Moreover, even this function gives the wrong answer. According to the )set mess bot on message, the test function is taken from the domain (INT->INT), which is Mapping(INT, INT). Unfortunately, Mapping is an Axiom primitive and according to available documentation:

)show Mapping

   Mapping(T, S, ...)
      Mapping takes any number of arguments of the form:
         T, a domain of category SetCategory
         S, a domain of category SetCategory
         ...
      Mapping(T, S, ...) denotes the class of objects which are
      mappings from a source domain (S, ...) into a target domain T.
      The Mapping constructor can take any number of arguments. All
      but the first argument is regarded as part of a source tuple
      for the mapping. For example, Mapping(T, A, B) denotes the
      class of mappings from (A, B) into T.
      This constructor is a primitive in FriCAS. For more
      information, use the HyperDoc Browser.

In any case, according to Hyperdoc, there is only one function exported: (you guessed it) equality testing. I have no idea where the code is or how the testing is done. Equivalence of functions (lambda terms) is undecidable, so I suppose equality here means equality in implementation? But surely, p should be equal to p however you test it.

`FunctionCalled? p' is the type, synthetized by the interpreter, for the value of `p'. This is one of the very cases where the type of an identifier does not agree with the value it refers to in the environement.

I'm afraid the definition of FunctionCalled? shown above does not capture the reality of the computations going on -- and I agree it is misleading.