In the previous two bugs (Bug 1479908 and Bug 1486888) we made the existing observes/command functionality work with XUL elements in HTML docs to unblock XUL document removal. Now that we are looking to migrate XUL elements to HTML elements we need to make a decision about what to do. The comment at https://bugzilla.mozilla.org/show_bug.cgi?id=1486888#c2 and then the following discussion is still pretty accurate about the state of things:

There's some useful discussion about our options in Bug 1479908, mostly
centered around either:

(a) Implement the same thing in JS via Custom Elements and Mutation Observers
(b) Stop relying on this behavior. The basic idea here would be to store
state inside of a JS object instead of a DOM node, and have the observing
nodes get mutated when the state object changes.

My summary of the main questions around (a):

• Possible async bugs with changing these to use Mutation Observers instead
  of the current impl in XULDocument
• Possible perf implications of creating a bunch of Mutation Observers. One
  for each <command> to detect arbitrary attribute changes, but also if we
  wanted to dynamically detect new nodes that code created with [command=foo]
  I think we'd need a global Mutation Observer listening to every new node.
  Unsure how frequently that happens - maybe we'd be OK to require a manual
  wiring up in that case.

My summary of the main questions around (b):

• We'd need to come up with an API and prototype it (there's a strawman in
  https://bugzilla.mozilla.org/show_bug.cgi?id=1479908#c8)
• What would migration for existing code look like?