Test suites enable deprecation warnings by default, and many projects
have a "no warnings allowed" rule. By adding programmatic deprecation
warnings for the old APIs where there's no other way to it in a 3.3
compatible way, we make things more difficult for people that still
need to support 3.3. I'm OK with doing that when there's a concrete
payoff in significantly reducing our maintenance burden, eliminating
an attractive nuisance (I took that as far as removing
contextlib.nested entirely before coming up with ExitStack as a
replacement), or when there's a concrete benefit to the *user* in
migrating, but otherwise lean towards the "I want major Python
upgrades to be exciting, not annoying" school of thought most of the
time.

And yes, I'm biased through working on package stuff - all of that
needs to straddle 2.6+ and 3.2+ due to platform support requirements,
and I want people to be free to work on metadata 2.0 rather than
figuring out how to avoid new deprecation warnings :)

Your updated list of suggested near-term deprecations sounds a lot
more reasonable to me - that stuff is all 3.3 specific, and the
packaging ecosystem hasn't really adjusted to those yet anyway (given
the heavy 2.6+ and 3.2+ bias). It was mostly the method deprecations
that bothered me, since providing the "lowest common denominator" APIs
is the easiest way to implement cross version compatible finders and
loaders.