When "Invisibles" were introduced, a function was either always-invisible or always-not-invisible. You couldn't make a function that "sometimes returned an INTEGER!, and sometimes was invisible."
Due to changes in the way the evaluator interacts with invisibles, this doesn't need to be a rule anymore. There could be functions which decide--perhaps based on their arguments--whether to act invisibly or not.
This has actually been requested. Imagine you are dealing with something like DUMP, and you want to call out that you'd like to actually return one of the things you are dumping:
all [ ... x * 10 + 20 ; want to print this expression and see its evaluated result ... ] => all [ ... -- (x * 10 + 20) ; now it's not participating in the ALL anymore ... ]
@gchiu wanted some way of getting a printout like
-- (x * 10 + 20): 40 but also having the value still returned, without needing to name another operator. So maybe you could mark this, e.g. with a GET-GROUP! or GET-WORD! in the DUMP dialect.
Having this particular debug construct behave in that way may not be the best idea in the world.
But we don't need to technically prohibit it.
This could give an interesting nuance to the difference between return and return void. RETURN used alone could just mean literally "return and don't have any value, not even void". It's certainly a weird idea, but it's consistent...and we could make sure you knew what you were doing by requiring some kind of invisibility in the type signature of a function before allowing a 0-arg RETURN. Of course there could be other syntaxes, like return/invisible...which would probably fit practice better by leaving plain RETURN as returning void.
There'd need to be a new syntax for saying you could return invisibles, because
return:  as the indicator wouldn't allow you to specify it along with other types.
The main argument for opportunistic invisibles is to keep you from having to create different names for the invisible and visible forms of a function, when there could be a learnable convention for knowing which it is from the arguments alone.
The more fanciful argument is creating strange execution patterns in code golf, where you have some kind of "voting" mechanism e.g. inside an ALL and program behavior emerges from things opting out. This harkens back some to the "null opts out of logical operations" ideas from the early days of null behavior.
Normalizing invisibles to the point of saying that they're what you get when you just do a plain RETURN is a fairly weird idea, but they're a pretty powerful feature that might have even more applications than yet thought of. most free-form programming language ever created is still the goal, so... I think this deserves some consideration.