We’ve repeatedly provided you the path to moving forward with this proposal. Make a custom element to provide what you want. Publish it, push it to the community, get them to adopt it. If enough developers see it as something useful and compelling, they’ll use it. Then browser vendors can see it provides some real value and they may implement it internally. This is how things work since the Extensible Web Manifesto was pushed.
You have yet to provide a compelling enough case that this adds desired low level functionality that developers simply can’t reproduce today with what we have. So, it falls to you to push a custom element providing the functionality and getting it widely used enough for browser vendors to then adopt it internally.
This helps prevent an abundance of confusing elements that have vague applicable uses from getting into the standards. Browser vendors focus on functionality that provides a big benefit to developers and more importantly users of the web.
With that being said, I don’t have anything left to offer this conversation. That’s the path forward for you. I’ve voiced my concerns over the element’s use and even what it should be called. Whether you agree or not, I believe it is not a good word for a new semantic element given the desired context. You seem adamantly opposed to this. Great. If your idea is so fantastic and highly needed, you have the tools available. Go build a custom element and prove me wrong by getting the web community to adopt it widely and show you’re right and browsers should adopt this internally. Until that is done though, I don’t see how this can move forward given how I understand the standardization process to work.