While a user could technically extend / override / wrap methods defined in this document a user would always face the problem how to deal with the asynchrony rule. I.e. when taking this spec seriously each extension of functionality should be done inside the handler that is run asynchronously from the actual `onX` invocations. However, these kind of extensions aren't possible just by implementing the interfaces here (or wrapping / overriding) but always need more heavy-lifting that will have to be provided by the implementations of this spec.

This makes a very real difference when compared to `Iterable`/`Iterator` case where implementing, wrapping, and overriding, etc. is always an option. 

So, IMO it should actually be discouraged to implement these interface directly. These are just the interfaces, the facade through which different implementations can communicate. To be sure: clearly signalling that these interfaces shouldn't be implemented by users is *not* meant to shield them from doing anything wrong but it's because the interfaces cannot be implemented without providing more heavy-lifting. It should be task of the implementations to provide all of this heavy-lifting to allow users to create instances of these instances by whichever means an implementation is able to provide. 

I think this is still valid even for the simplest implementation that just uses JDK tools like `Executors` for enabling asynchrony: you cannot just implement the interfaces (and much less wrap or override) but usually you will want to have at least some infrastructure helping with implementing them.