Jon,

You're right. The "Not that it matters" was wrong because the problem is
that it's looking for a public reference.

Here's what I did and I should probably be thrown in jail for doing this,
but it almost seems to have worked.

MethodInfo ovc = typeof(MyControlClass).GetMethod("OnVisibleChanged",
BindingFlags.NonPublic | BindingFlags.Instance);
Delegate ovcDelegate = Delegate.CreateDelegate(typeof(EventHandler), this,
"VScrollBarValueChanged") as EventHandler;

FieldInfo fi = typeof(Delegate).GetField("_target", BindingFlags.NonPublic |
BindingFlags.Instance);
fi.SetValue(ovcDelegate, myControl);
fi = typeof(Delegate).GetField("_method", BindingFlags.NonPublic |
BindingFlags.Instance);
fi.SetValue(ovcDelegate, ovc);
fi = typeof(Delegate).GetField("_methodPtr", BindingFlags.NonPublic |
BindingFlags.Instance);
fi.SetValue(ovcDelegate, ovc.MethodHandle.Value);
fi = typeof(Delegate).GetField("_methodPtrAux", BindingFlags.NonPublic |
BindingFlags.Instance);
fi.SetValue(ovcDelegate, ovc.MethodHandle.Value);
parentControl.VisibleChanged -= ovcDelegate as EventHandler;

Basically, what I did was I created a dummy delegate that had the same
signature (though I don't think that really matters).

Then, using reflection, I filled in the all the fields of the Delegate with
the information for the event handler I really wanted a delegate for.

Now, as I said, this "almost" worked.

It did appear to successfully remove the old reference. But somehow, it
created an entirely new reference with a call stack leading back to

parentControl.VisibleChanged -= ovcDelegate as EventHandler;

This is according to .NET profiler... The relevant portion of the call stack
is:

MulticastDelegate.RemoveImpl(Delegate)
Delegate.Remove(Delegate, Delegate)
EventHandlerList.RemoveHandler(object, Delegate)
Control.remove_VisibleChanged(EventHandler)

How does that create a reference? Unless it's walking the stack to see where
the call is coming from and saying, "Aha, this is a different class trying
to unsubscribe the original subscription, so let's keep a reference to the
new one..." I don't know. My head is about to pop.

In reference to this, I'm not sure I understand what you mean. Doesn't the
unsubscription need to have the same underlying function pointer (it appears
that's technically how it's happening underneath with the
Delegate._methodPtr)...

Unless I'm misunderstanding, your method would unsubscribe a different
_methodPtr...