We have always had languages that were preferable to be used in a particular scenario. For a quick prototype development, VB6 was an obvious choice. VB6 was chosen in projects that had a simple desktop user interface and standard and un-complicated database interaction requirements. If you wanted to develop a device driver using low-level routines, you probably relied on C or Visual C++. ASP was a standard choice for development of web interfaces. Every language had a particular ‘domain’ or ‘specialization’, speaking crudely.
With .NET framework, all languages are interoperable and presumably consistent. You can have a project with modules from different languages all together but all ultimately being treated fairly similarly (all get compiled to IL).
Does this mean that the distinction we had earlier no longer exists? That differentiation was not necessarily bad rather something that was there by design and not due to any constraint. That apparently is diminished somewhat with the .NET framework and its treatment of various languages.
The language distinctions remain. It does not really make a difference whether you compile a language to assembly code or MSIL, except that maybe the abstraction level of MSIL is higher than that of assembly.
The big advantage of .Net though, and this may have inspired the question, is that you can use object code of language 1 in a library written in language 2 linked by an application written in language 3.
Long time ago, before there was electricity and auto-mobiles, you couldn’t simply use C-generated .obj files in a Pascal or Delphi application (and vice versa) without explicitly wrapping them in a DLL (and taking care of the calling method and parameter sequence and parameter compatibility), or calling out to another executable.