$NumberP includes cases like Rat(2/3) = ((MRAT SIMP NIL NIL) 2 . 3) as
opposed to 2/3 = ((RAT SIMP) 2 3).
There are many cases like this where there are two or three subtly
different routines in Maxima. Sometimes it is because there is a
legitimately but subtly different requirement; sometimes because there
is a subtle efficiency issue; sometimes because the author of the second
wanted to be sure to handle a case that the first didn't handle, but
didn't dare change the first, in case s/he hadn't fully understood some
subtlety; and sometimes simply because the author of one routine was
unaware of the existence of the other.
In this particular case, MNumP presumably never gets called where
Rat(2/3) is possible (e.g. within a General Representation expression
other than MList, etc.), and so gains a couple of cycles of efficiency
compared to $NumberP (though I would not be surprised to find some funny
corner cases which really should be calling $NumberP, not MNump). I am
a little puzzled by Rich's phrase "whatever $ratnump etc means at the
time it is called" -- $RatNumP is a builtin, and presumably its
definition doesn't change....
Unfortunately, many parts of Maxima make assumptions about the
representations used by other parts (no opaque data types here...),
which makes it difficult to update representations. In particular,
using Common Lisp rationals or complexes would probably break things in
the system which assume that NumberP implies RealP and NumberP and Not
FloatP implies IntegerP. I have no clue how many or how few such cases
there may be.
-s