I disagree, and that gets us nowhere, does it? :-)

Assume we're introducing only the bound method pointer, that is, an object
that:

o - is typed just as a method is, with a specific "this" type, argument
types, and return type.
o - when created, is bound to a "this" object and a method name
o - does only one thing after being created -- call the method it was bound
to

I submit that, to anyone familiar with OO (in particular, dispatch of
virtual functions), the idea of an object that encapsulates a method call is
an obvious one.  I submit further that there are no bothersome subtleties
here.  Having written one test program that used these method pointers,
you'll know exactly how they work, and the answers to whatever questions
might be raised are obvious.

Q: What if the object gets collected?
A. The method pointer references it, so it can't be collected wile the
pointer's still live.

Q. What thread does the called method run on?
A. The same thread as the caller, like any other method.

Q. How many times can I use a single method pointer?
A. As many times as you like, just as you could call the method directly as
many times as you like.

Anonymous classes are, I submit a bit more complex.  Yes, they're classes,
and that answers a lot of questions about them.  But their access to the
private parts of their enclosing class (necessary, if they're going to be
useful callback handlers) introduces more complicated and somewhat arbitrary
behavior:

Q. But what use are they if they can only invoke public behavior on their
enclosing class?
A. Exactly.  That's why they can access private parts of their enclosing
class too.  And their enclosing classes can access their private parts too.

Q. Why that last part?
A. Umm, symmetry.  And they can access final members of the block that
creates them.

Q.  You mean, scalars and strings, that are truly constant?
A.  No, objects too.  Including mutable ones.

Q. So the anonymous class can access an object that might change out from
under it, but not an object *reference* that might change out from under it?
A. Exactly.

Q. And I can define static members of the anonymous class, to define
properties that all of the instances will have in common?
A. No.

Q. Why not?
A. Because. But you *can* define them as statics on the containing class,
further away from where they're used, and with nothing syntactic to indicate
that they're intended as part of the anonymous class.

Q. OK, I feel better.    But it seems to me that the purpose of the
anonymous class is to make its methods as much as possible like methods of
its enclosing class, while allowing them to be run from a wider selection of
callers, for instance, via callback interfaces the enclosing class doesn't
implement.
A. Exactly.

Q. Then why not have a mechanism where the method *can* be part of the
enclosing class, and be called via something other than its name?
A. Because that would be complicated.

Anders Helsbeg.

Hmm?  C++ has had method pointers as far back as I can recall.  Certainly
they were described in the ARM.

I don't know if he was at MS early enough to have introduced them into J++.
He may well have been the one who introduced them into the .NET CLR.

One interesting thing about Sun's white paper is that it was written at a
time when Sun was suing MS for polluting Java with, among other things,
method pointers.