Improve and change the map-change event #1054

Some thoughts from Claude Opus 4.7:

Reasons it looks like a flaw:

• Platform events for state changes (change, toggle) all bubble and are composed, so users reasonably expect the same from map-change.

• The natural place to observe layer state is the <mapml-viewer> (single listener, works for dynamically added/removed layers). Requiring per-layer listeners forces consumers to manage subscriptions on every add/remove and misses shadow-DOM crossings without composed: true.

• It's dispatched from inside the layer control (the Leaflet-side UI), not from the <map-layer> itself as an authoritative state signal — so semantically it's more of an internal notification than a public event.

Reasons it may be intentional:

• The only in-tree consumer is <map-extent> listening on its parent <map-layer>. For that use case, non-bubbling is fine and avoids leaking an internal coordination signal up the tree.

• The event carries no detail payload and isn't documented, which suggests it wasn't designed as a public API surface.
  ed. note: it is documented, slightly

• If MapML.js wants it to be public, the fix is straightforward: new CustomEvent('map-change', { bubbles: true, composed: true, detail: { checked, layer } }) . If it's meant to stay internal, a better pattern would be a direct method call or a private Symbol-keyed event, and a documented public event (e.g. change on <map-layer> for consumers. ed. note: we made it map-change to avoid clashing with existing events' names, per a platform design principle.

In sum, it looks like it should be coming from the <mapml-viewer> and it should have a detail field that identifies where it came from, and it should bubble, and it should transit SD boundaries (componsed)