I gave my argument for why I didn't like to "b" being the kind of rule that automatically gave a value back...because if it generated a product, then that product would frequently need to be discarded.
But with the way the rules are currently working, they can know whether they are supposed to be producing a value or not. This avoids having to make separate "cheap" rules with skip in their name, distinct from "expensive" ones that don't have skip in the name. Some parser combinator libraries do this.
Hence I figured there was no harm in having TO become able to bear a value if it wanted to. Since INTO was the kind of rule that was asking for a place to look, it would qualify for switching TO into that mode. Easier to type than into [across to "b"]. So I made TO bear a value if there was potential for its usage.
But given what I'm looking at with yielding the last result of a PARSE rule by default for var: [your rule here], I think this is the wrong tradeoff.
That takes away the certainty of "rules knowing when they need to generate a product or not" . We can tell with a rule with no set-word that it won't assign a value, but once you combine a block with a SET-WORD!, no rule in the block a priori knows if it's the last. If we tried to enforce that it could know when it was the last--by means of lookahead and analysis to check if everything afterward was invisible--would mean we'd have to prohibit rules with side effects during argument gathering (as well as prohibit the phenomenon I call "opportunistic invisibility", which is less critical). I think that for the kind of freeform experience this is shooting for, we want to err on the side of imperative freedom...even if it costs us optimality.
But even so: if casual usages of seeking/matching rules are synthesizing new values when they're thrown away 90% of the time, that's worse than calling out the 10% where you do want it.
Instead, what I might propose is that @[...] become the syntax for ACROSS. This means instead of writing:
uparse "aaabccc" [into [across to "b"] [some "a"] to end]
You could say:
uparse "aaabccc" [into @[to "b"] [some "a"] to end]
This would become a means of converting any rule into a value-bearing rule, even if all of its component rules were "invisibles".
So I'm going to undo my addition that allowed the into [to "b"], and substitute the ability to say into @[to "b"]. Then see how well things can work with parse rules evaluating to their last value...