Enhancements to "the COMPOSE dialect" that make it easier to make GROUP!s in output have always been something I've thought about. My current best try is labeling the groups you want composed, which affords leaving groups you don't want evaluated as-is. But that doesn't help you if you wanted to evaluate something as a group, and coerce the product (likely a block) to a group, preserving any decorations on the slot.
Interesting idea to let ((...)) mean "groupify" instead of my thought of meaning "plainify". Probably more semiotic. In any case, I think you're starting to catch on to what dialecting is about!
Before you called it into question, I just sort of assumed you'd need it. But that's based on my instinct that it's not the only instruction in the box... that what people will ultimately want from "specifiers" is a more nuanced concept than a simple chain of environmental inheritance can provide.
I think it's probably about time to take a crack at prototyping the new model. I'm sure it will unleash a flurry of posts as I hit issues.
(As I say, the "start the world unbound and let the binding trickle down" was tried before...minus the quoted material not getting trickled tweak. But also, I was still trying to make PICK-ing and FOR-EACH-ing propagate that trickled specifier in a way that gave the illusion of the old binding model, so dialects could just GET the products, instead of making them say where to BIND and do their own trickle. Implicit propagation was a dead-end: the eagerness of putting binding on meant you were pretty much always binding something that already had a binding on it. There had to be a merge binding strategy... more complex than the hole-punching... to accomplish even the most basic things. This merge binding led to cycles I've previously mentioned, and other intrinsic problems. What we're talking about now starts limiting the problems to COMPOSE scenarios...the problems will still be there, but hopefully more manageable.)