It does make sense to mix languages inline IF (and almost only if) they are NOT closely related.

It seems plausible that the most sensible use, especially long term, for the P6 language mixing capabilities, will be to use noticeably dissimilar langs and DSLs.

Note that this can be P5 and other langs just as it can be P6 and other langs. In other words, one way to treat P6 is as a framework for P5. This way you get the non-lang benefits of P6, such as the fact that its P5 will (presumably) soon run on Android, and has a really nice debugger, etc. without the distraction of P6 syntax.

The principle that different things should look different is associated with Larry Wall, a linguist, the guy who designed P5 (and P6). In other words, yes, he's very sensitive to this issue of confusing similarities (and I reckon hundreds of others that relate to human and computer languages).

When I said "there are heavy downsides to mixing langs like this" I specifically meant P5 and P6 and the issue that their similarity can be confusing. But I also said "I don't agree that those downsides are so great that it never makes sense to mix langs inline, even ones that are closely related" by which I specifically meant P5 and P6, on occasion (which perhaps agrees with your "almost" qualification in "almost only if"?).

It totally makes sense for folk to avoid inline mixing of P5 and P6 (or one of these and PHP or whatever other similar looking langs are available for inlining) if they can get the job done another way. But, imo, having the option available to mix them if one is in a tight corner time/skills/resource wise, during the years of transitioning from using just P5 to using a mix of P5 and other langs, is a valuable one, one that makes P6 more valuable for P5ers, not less.