Dynamic scope in Maxima is a remnant of the historical context Maxima
was developed in, and I'm pretty sure that it should be changed at some
point. But this would change many things.
Consider global behavior flags, e.g.
block([numer:true],%pi)
For this to work, we'd have to have some way of marking *some* variables
as fluid.
Now consider localy: block([y],y) vs. globaly: y. Is localy=globaly?
That is, does ev(localy,y=3) return y or 3? If localy does not equal
globaly, what does it equal? Can you see the difference between the two
when they are displayed, or does ratsimp(globaly-localy) => y-y ?!
This sort of thing is the consequence of the punning between
mathematical and programming variables in Maxima, which often comes in
handy, despite having peculiar semantics.
As you say, if Maxima dealt with true functions rather than expressions,
much of this would become simpler. But I don't see how you would design
a workable system on that basis, since traditional mathematical notation
is heavily based on named variables.
So I think we'd have to analyze the question more closely at some point.
It is not a minor change to the semantics, and it does require changing
(as Rich points out) the translate-to-Lisp package as well as the
debugger, and checking existing code written in the Maxima language
(e.g. the Share directories, not to mention user code) to see how it is
affected. It is not something we can treat as a bug fix and rush into
production.
And frankly, there are lots of other weird things in Maxima
semantics....
-s