It will still be confusing. At some point you'll need a library that doesn't support it. ".NET" promised backwards compatibility. Now, old ".NET" stuff won't work where you'd previously expect it to. Everything was quite clear when these 2 incompatible platforms had separate names. It's like merging Java and JavaScript "for clarity".
Except for 2.x-3.x, .NET Framework didn't provide backward compatibility across major versions, so a break at the 4.x-5.0 transition would be in line with .NET Framework history even if .NET 5 was viewed as .NET Framework 5. Which seems to be why the version of what is basically .NET Core after .NET Core 3.x is .NET 5, so it fits expectations whether viewed as a .NET Core version or a .NET Framework version number.
Enterprise will no doubt keep legacy .NET Framework 4.8 around for legacy apps—the same way they do Framework 1.1 and 3.5.
> It's like merging Java and JavaScript "for clarity".
Not really. .NET Core can be viewed as just a production-ready but not feature complete early release of the next major version of .NET Framework, which involved major reengineering, and which will be released as .NET 5 when it is feature complete.
You already need .NET Framework 1.1, 3.5, and 4.8 to ensure you can run anything ".NET" due to past compatibility breaks. This is just another one in the chain and why major version numbers exist. You'll be able to install all of them side-by-side just like you can now and the only issue is if you want to use dependencies that only target a different version than you're currently using.
