It's a bit of a pain to collect alternate rules. For instance:
alternates: copy  rules: [[some integer!] [3 text!]] for-each rule rules [ append alternates compose [(rule) |] ] uparse data [alternates]
That will give you alternates as [[some integer!] | [3 text!] |]
But that rule will always succeed...should both the component rules fail to match, it will act as a no-op. Because it's equivalent to [[some integer!] | [3 text!] | ], and  will always succeed.
You get a similar problem if you go the other way.
for-each rule rules [ append alternates compose [| (rule)] ]
Now you've got a rule that is always a no-op: [| [some integer!] | [3 text!]]. Again, this is equivalent to [ | [some integer!] | [3 text!]], and this time the  succeeds before the other rules get a chance.
You can hack around this by starting out with alternates: [false]. This way, you can add the [| (rule)] and it will never run the false. So it works.
Wouldn't a New Meaning for the ANY Combinator be Better?
Having reclaimed ANY it seems it would be perfect for this. Why not:
rules: [[some integer!] [3 text!]] uparse data [any rules]
You could leave your block in its regular old form, and use it that way. Dyn-o-mite!
But wait. BLOCK! already has semantics as a parse rule. Conventionally, ANY doesn't get to see the block at all... it gets a parser function which has been made out of the block.
Bad Option #1 - Quoting
So ANY could say it's a quoting combinator. This means it would get whatever single thing came after it... be it a WORD! or BLOCK! or whatever. It could try its best to turn that into a BLOCK!.
In the case above ANY would thus get the WORD! rules. It could look up the WORD!, get a block. And then walk through the block, combinatorizing each element in it and running the element in sequence.
That's rather yucky.
Less Bad Option #2 - Take BLOCK! as synthesized rule product
ANY would be a better citizen if it was willing to say that the BLOCK! it's going to walk through came to it by honest means.
rules: [[some integer!] [3 text!]] uparse data [any (rules)]
At first glance that seems weird to me. But, is it really that weird?
It seems to me this is what has to be done--and it makes much more sense than going down the rabbit hole of quoting and destabilizing the whole syntax.
Also, This Mitigates Compatibility Concerns
If ANY only runs with rules that have BLOCK! synthesized products, that's a (small?) subset of all the ANYs that are out there historically. It can choke if it doesn't like what it sees and tell you that you may be using the old sense of ANY.
Even further, we probably can temporarily make ANY a quoting combinator that only accepts GROUP!...as a simulation of accepting any parser in the future.
I'm going ahead and adding it!