Good, my turn to confuse matters (i.e. create a mess that Jon has to clean  
up :) ).

The first paragraph is correct for sure.  I remain unconvinced that it's  
untrue for Control.BeginInvoke(), at least as an unqualified statement.

Consider the statement in the doc page for IAsyncResult.AsyncWaitHandle:

    Notes to Implementers The object that implements IAsyncResult
    does not need to create the WaitHandle until the AsyncWaitHandle
    property is read. It is the choice of the IAsyncResult
    implementer. However, if the implementer creates AsyncWaitHandle,
    it is the responsibility of the implementer to signal the
    WaitHandle that will terminate the wait at the appropriate time.
    For example, System.Runtime.Remoting.Messaging.AsyncResult
    terminates the wait on behalf of the caller when an asynchronously
    invoked method returns. Once created, AsyncWaitHandle should be
    kept alive until the user calls the method that concludes the
    asynchronous operation. At that time the object behind
    AsyncWaitHandle can be discarded.

In other words, if the caller to Control.BeginInvoke() actually uses the  
AsyncWaitHandle from the IAsyncResult it gets from Control.BeginInvoke(),  
then that WaitHandle (which implements IDisposable and so must be disposed  
when it's no longer needed) is required to be kept until the "_user_  
[emphasis mine] calls the method that concludes the asynchronous  
operation".  In other words, the user's code has every reason to expect  
that the WaitHandle will remain valid until that code calls  
Control.EndInvoke().

So code that gets the AsyncWaitHandle is going to have to call EndInvoke()  
to ensure they clean up that resource properly (EndInvoke() baing "the  
method that concludes the asynchronous operation".

Beyond that, even if you can show in the current Control implementation  
that there's no harm in not calling Control.EndInvoke(), I would say that  
absent some clear, explicit statement in the MSDN documentation pages that  
says that you don't need to call EndInvoke(), that pairing the two calls  
may well be important, and very much _should_ be assumed to be so, at  
least if your code uses the AsyncWaitHandle in the IAsyncResult, if not in  
other cases.

I've looked for such a clear, explicit statement and haven't been able to  
find one.

I'm carefully ignoring the fact that Control.BeginInvoke() doesn't follow  
the normal pattern for async methods.  There's no way to specify a  
callback, never mind a context/state object for the callback.  This means  
it's practically impossible for the asynchronously invoked method to have  
access to the IAsyncResult (it's not literally impossible, but it's  
impractical because any attempt to provide access results in a race  
condition...that can be addressed by adding thread synchronization, but  
then that seems to me to negate the whole point of using BeginInvoke() in  
the first place).

This means that if you _do_ call EndInvoke() you have to do it somewhere  
other than the invoked delegate.  This leads to inelegant things like  
polling IAsyncResult.IsCompleted, or just calling EndInvoke() and possibly  
getting blocked anyway.  I suppose there are situations where this is  
actually what you'd want to do, but being forced into seems kind of ugly  
to me.

In other words, it bugs me that the whole Control.BeginInvoke() API is the  
way it is.  While I can understand the need for backward compatibility, I  
don't understand why it remains in this sort of awkward state rather than  
adding some overloads to Control.BeginInvoke() to allow it to be used in a  
more typical fashion.

I suspect that as long as you do nothing with the IAsyncResult returned by  
BeginInvoke(), you're fine.  But I wish there was some more explicit  
documentation to that effect.

One feature of delegates is that they are not specific to whatever method  
they might be passed to.  You can create a single delegate that is  
suitable for either Control.BeginInvoke() or Delegate.BeginInvoke() (and  
for the synchronous Invoke() equivalents as well).  The delegate does not  
need to be related to the Control class at all, never mind be an instance  
member, or a member of any Control-derived class of any sort.

The corollary is that the delegate itself doesn't "know whether to be"  
anything in particular, nor does it need to.  The sole determining factor  
is how you use it  If you call Control.BeginInvoke(), then it's used by  
Control.BeginInvoke(), executed on that Control instance's owning thread.  
If you call Delegate.BeginInvoke() on the delegate instance itself, then  
it's invoked asynchronously via that method.

Pete