> Since all languages compile to the same representation on silicon (give or take a few opcodes)

I'm not sure that this is the case.

It depends how we're defining "representation", but I'd argue that languages are definitely more dissimilar here than they are they same. If you want to mix and match two compilation units with the semantics of different languages, even something as simple as a cross-language if-statement is going to be a hard bridge to cross, and even when targeting a single runtime it's easy to have a syntactic layer which doesn't efficiently map to that runtime.

That said, for the first thing they asked for (different syntactical views on the same "substrate," where I'm assuming the language has one model of how its runtime works), that's very doable.

> compilation units

Is this a universal concept?

No. It's a common enough term, but the handwavy concept I wanted to get across is that if you have code mixing and matching different syntaxes then there will necessarily be boundaries between those. Code with one syntax (if you can actually mix and match runtimes as the comment author said they want) will behave differently from "adjacent" (commonly a different file or directory, but I could imagine multiple syntaxes within a file too) code with a different syntax.

In common languages, you're usually still targeting the same runtime in different compilation units, but it's a rough description of optimization boundaries (you compile one unit at a time and stitch them together during linking). Some techniques bridge the gap and thus the language crispness (e.g., post-hoc transformations on compiled units, leading to one larger "effective" compilation unit), but you can roughly think of it as equivalent to a whole shared library.