I try to never say never--many proposals pop up and someday things may get to the point where a weird idea becomes needed. The "SCRUNCH!" proposal is one of the things that nags at me now and then as expanding the expressive space so much that it may turn out to be a good idea after all.
But at the moment, composite sigils address only one small problem in multi-returns that's been on my mind... while they introduce countless usage and implementation questions.
Bear in mind that the things you see here aren't implemented by a magic genie. I have to write some sort of code for them. And even "small" changes have wide-ranging ramifications. Only just today have I been able to lift the limit of 64 datatypes so the full byte in the cell can be used. (I will probably write up why the legacy of the uint64_t TYPESET! implementation ended up being such a difficult design point to overcome.)
Anyway... so if I say I have no clue how to get something to work without wrecking the implementation or having bad impacts on userspace code, that's actually a pretty strong vote against even the biggest hunch one might have (even if it's my hunch).
If you wind up sticking around and hacking on Ren-C instead of developing your own language--and want to pick composite sigils as an area of study--then a fleshed out implementation would certainly be given due consideration. However, there's some combination of I don't know how to do it along with I think the result would wind up being ugly and complicated ... whereas I mostly know where the current path is going and am largely at peace with it.
Note that this is what [^x]: does, and I'm not particularly bothered by needing a block for the few times it comes up (if anything, it improves visibility).
Using blocks and groups as structuring parts helps you distinguish between e.g. that and ^[x:]. So to me, they are the mechanism for accomplishing composition.
Introducing ANY-FENCE! to bring in another array type will give another tool for structuring. And as I mentioned, it will be a good composable choice for picking the main return result out of a multi-return.
[x {y} ^z]: ...
[x y {^z}]: ...
That's something we have a vocabulary and API and mechanism for, and I think the ergonomics in sum surpass what a system based on multi-sigils would be like.