I finally figured this out.  The try/except statement is a complete red
herring; the problem is in the raise statement.  The behavior is the
same in 2.4, 2.5 and 2.6, even though Exception is a classic class in
2.4 and a new-style class in 2.5 and 2.6.

The rules are relatively straightforward, and explain all observations,
once you realize that attempting to raise something that is not allowed
raises a TypeError:

- you can raise strings (except in 2.6 -- see footnote)
- you can raise any classic class
- you can raise any class that derives from [Base]Exception

(That last rule is subtle, due to standard exceptions changing from
classic to new-style in 2.5.)

I do not believe that there is anything wrong in this set of rules, and
would object to a change that would allow raising any new-style class in
2.6, since this would be a temporary relaxation of the rules, whereas in
3.0 we will be significantly *tightening* the rules!

PEP 352 states that in Python 2.7 we will deprecate raising exceptions
that don't derive from BaseException; in 2.8 we will deprecate catching
those; and 2.9 we may deprecate __getitem__ on exceptions.  This was
written before 3.0 was really planned; IMO we should have "-3" warnings
for all these things in 2.6.  This implies that "except object:" will
get a -3 warning -- but not a deprecation warning.

I do recommend that these rules be documented more clearly.

(Footnote: if I read PEP 352 carefully, I don't believe raising strings
was supposed to be disallowed before 3.0.  I'm not sure it's worth
reverting this though.)