null namespace in DOM L3 Events inconsistent with other specs

From section 1.1

For backward compatibility reasons, the dispatching of an event will ignore namespace URIs if either the event or the event listener has a null namespace URI.  If a DOM Level 2 event (i.e. with a null namespace URI) is dispatched in the DOM tree, all event listener that match the type will be triggered as described in Description of event flow. If a DOM Level 3 event (i.e. with a namespace URI) is dispatched in the DOM tree, all event listener with the same type and the same or null namespace URI, will be triggered as described in Description of event flow.

-------------------

This basically results in a null namespace parameter to addEventListernerNS acting like "*" in getElementsByTagNameNS.  It also has the effect of discouraging use of  common event names (like "load") in arbitrary namespaces since existing DOM L2 Event clients would receive those messages in addition to the intended {http://www.w3.org/2001/xml-events}load and {null}load events.

The motivating factor is to not break existing event handling code while effectively changing the DOM defined events from not being in a namespace to being in {http://www.w3.org/2001/xml-events}.  Instead of having addEventListenerNS(null, "load") or addEventListener("load") receive any event named "load", it would not be difficult to define the behavior so that it would only get {http://www.w3.org/2001/xml-events}load and {null}load events.

One mechanism to accomplish this would be to add an additional boolean parameter or the init*EventNS's that mark the event as being dispatched in a compatibility mode.  If this parameter was set on the event, then the event should be dispatched to any listener that matches its namespace and event type or any listener registered with addEventListener() or addEventListenerNS(null,) and its event type.

The second option would be to imply that behavior for any event in {http://www.w3.org/2001/xml-events}.