We're unlikely to pursue this, at least in the near term:

• No one else has ever asked for it.
• It serves an awkward place between user friendly tools like the Batch Editor and full-power API/CLI tools, but is way worse for us to build/maintain than those things are.
• The DOM isn't a stable API and we don't want to encourage users to use it like one (see T4213: Provide custom themes, skinning, or custom CSS for discussion). Particularly, this bit applies fairly well to including other markers in the DOM, even if the goal is Greasemonkey scripting rather than themeing:

If we'd had theming support a year ago, everyone who had written custom CSS would have had their theme completely broken multiple times. If we provided support today, everyone's themes would almost certainly break a dozen times in the next year. There's no way we can avoid this while still moving the software forward as quickly as we do: providing custom CSS support basically makes all of our CSS and HTML a public-facing API, but an API which is highly unstable, has huge surface area, and is impossible to document or version effectively.

• (Even though you personally may be fine with your stuff breaking, historically users use stuff we provide and aren't happy when it breaks. Even if the original author is fine with it, people will give stuff to coworkers and then they get upset when it stops working, etc., etc.)

We are more open to providing ways to automate workflows via the supported tools. If there are specific things which are hard to do in bulk right now, we'd at least be interested in hearing about them.