The JMX API and JMX Remote API define clear semantics for notifications.  If you listen for notifications remotely, you are guaranteed either to receive all the notifications you are listening for, or to be told that you may have missed some.

This guarantee is not necessarily enough, although ultimately it is never possible to provide an absolute guarantee of anything better.

The JMX API could define an event-handling mechanism with greater reliability.  One possibility would be an event-handling MBean that receives all notifications sent by other MBeans in the same MBean Server.

This MBean could do two things with those notifications, not mutually exclusive.  One would be to maintain a list of interested clients, and store up the notifications for each client until the client claims them.  A complete end-to-end acknowledgement would ensure that a client that fails after receiving a notification but before handling it does not lose that notification.  The behaviour of the MBean in this scheme is not very different from the existing fetchNotifications mechanism defined by the standard connectors in the JMX Remote API, but since the MBean knows which notifications are still of interest it can respond better to heavy notification traffic.  The fetchNotifications mechanism has to hold on to all notifications for as long as it can, because by design it never knows when a notification is no longer of interest to anyone.

The second possibility would be for the event-handling MBean to have pluggable treatment of notifications.  For example, you could plug in a JMS bridge that would send notifications of interest to a JMS topic or event queue.  Because JMS is not part of the J2SE platform, such a bridge could not be supplied by default.