I said that I would give my opinion on this. So, what follows is that: just my own personal opinion.
Let's call the functionality evalat, just to distinguish it from 1-argument eval.
I think that the behaviour in the posted example shows something that could (and should) be improved.
One scenario that concerns me here is that in which the calling of evalat is made deep inside some routine in the shipped Maple Library. That's quite different from cases where the user calls it interactively (directly) at the top-level. I'm thinking of cases where there is no chance for the user to intercede and choose to do some different analysis of the expression at or near the point.
And, as I only found out only a few days ago, this very example was such a case. The user received an answer for a complicated computation that turned out to be wrong. This (longstanding, expert) user was fortunately able to recognize that the result was wrong, and was able to trace the problem back to this particular evaluation at a point, which was being done within some Library routine. So there was no clean and simple workaround -- no immediate way to make the Library routine take some other approach.
As a Maple user, I would be prepared to take a small performance penalty if evalat could be improved here. If one wanted to use a super fast but mathematically unsafe evaluator then one could make do with subs, which is more intended for substitution into a data structure. But eval is supposed to be the smarter, mathematical safer evaluator.
And the improvement should be centralized. I don't buy a line of argument which says that individual Library routines all ought to be more careful in their use of evalat. The evalat functionality is used very widely within the Maple Library. If Maple's going to be improved to be stronger in its zero detection when evaluating expressions at points, for mathematical computation, then that should be done centrally.
Maple is not finished. No computer algebra system will ever be perfect. But the competition will improve, and thus so must Maple. I think that we ought to be able to seriously revisit this kind of functionality at least once every few years. It's in the class of issues for which -- while perfection is unattainable -- incremental, practical improvements are good.
This problem should not be impossible to cover adequately. Perhaps radicals could be dealt with at object simplification/uniquification time. Eg. 27^(1/2) -> 3*3^(1/2) automatically. Having evalat revert to substituting `^` by root and sqrt (as shown here) would be prohibitively expensive.
An extensible, user-customizable solution might be cheapest, if the default behaviour were not changed. That's because the system would only have to check something simple like a flag. And the user could choose how hard the system ought to work at zero testing. But then, how helpful would it be, if the default behaviour were left as it is?
Mathematical Software, Maplesoft