Hmmm! I have always thought that an unqualified '&' was enough to signal that what comes after it is not part of the command before it. In fact (being quite naive) I have thought that one of the first things done was to separate a compound command at the command separators.
Well, that'd be (1) incompatible with every other command interpreter, and (2) break almost every batch file that uses pipes. Or compound commands. Or conditional commands.
In your simple (but not real-world useful) example, the "echo foo" could reasonably be executed at the parent process level, not in the child pipe process. (Though there isn't any benefit in trying to pass it back to the parent.) But what about:
Cmd3 can't be executed by cmd1, because (1) cmd2 already ate all the output, and (2) cmd3 expects the output to be coming from cmd2.
Similar problems exist with && and || - they need to be the result of the preceding command, not the parent.
So what you're asking is for the parser to automagically determine whether anything on the right side of a separator (&, &&, |, or ||) *might* not have any interaction with the command immediately preceding it. Without knowing what the command (especially an external) is going to do. And what would be the benefit - not having to worry about whether you redefined colors just before executing a pipe?
The current (correct!) behavior is how it's worked for the last 25 years or so. If you want everything executed in the same shell, use DOS pipes.