The root cause of this behavior is that 0^EXPR is simplified to 0 without
requiring that EXPR>0. The syntactic form of EXPR doesn't matter.
So 0^a and 0^(-a) simplify to 0, but 1/(0^a) simplifies to 1/0, which gives
an error when simplifying.
In principle, Maxima could:
0) simplify 0^EXPR to 0 when EXPR is not known to be negative -- the
current behavior; note that 0^(-x^2) *does* cause an error;
1) leave 0^EXPR unsimplified when EXPR is not known to be positive
2) return something like (if EXPR>0 then 0 else ERROR) -- but Maxima does a
very poor job of manipulating/simplifying if-expressions;
3) ask the user about the sign of EXPR -- which is problematic for
programmatic use of Maxima, and annoys some users;
4) assume that EXPR>0, and warn the user that it's made that assumption, or
incorporate the assumption into the value -- RJF's "caveats".
This is one of those cases where ease of use is in direct conflict with
correctness, and over the years, different people on the list have
expressed a preference for different defaults. Generally, Maxima seems to
lean towards ease of use, thus for example x/x simplifies to 1 without any
requirement that x<>0. Some users have even argued that 0^0 should simplify
to 1.
Moving to a Maxima which does a better job with if-expressions or that
implements 'caveats' would make solutions (2) and (4) more attractive, but
I think right now the choice is between (0), (1), and (3).
-s