> Basically, the issue is that developers have a two-fold expectation of
> a subprogram pointer, namely, to support indirect invocation and also
> subprogram identification.
  Right.  It's quite unreasonable to expect that something designed for
the former will just happen to also support the latter, and the developers
shouldn'a done it.  In addition to the generic wrapper situation, think of
a system where a subprogram can have different addresses during the course
of execution.  A system with multiple loosely coupled CPUs each of which
may have its own copy of parts of the program in its own memory, for instance.
  The only language change that seems reasonable would be to eliminate the
"=" operator for subprogram access types.  That probably wouldn't be very
helpful for your situation.  You could educate your developers about using
dispatching instead of callbacks.  That would be a good long term approach.
  In the short term, how about a memo like:
To: Software Developers
Subject: registering callbacks
  Many systems currently un-register a callback by means of a second call
like "unregister(routine'access);".  This is slow, since it involves a
search by the registrar, and it's not safe, since different
"routine'access" can in fact return different values, for instance in
generics or multi-processor systems.  It's both faster and safer to
[description of your preferred variant of (c), the ID/laundry tag system].