This is not unusual in Microsoft-land. If a tech stack or version is very widely adopted or heavily revamped in a new version, they will often support that old version for a very long time - see Windows 7.
The name scheme was confusing only during the "overlap" period. At this point again you can strictly pay attention to version numbers: 8 > 7 > ... > 4 > 3 > ...
Any version < 4 is out of security support. Only one version number starting with 4 remains in security support but you don't want to use it if you can use a higher version number. .NET 8 is new/fresh/current LTS. The rest of the "naming scheme" is dead weight.
- Disappearing community support (many common/favorite libraries have already dropped 4.8 support and/or maintenance and are only looking at the .NET 5+ present; more do that every day and generally greenfield fresh/new libraries won't even consider 4.8 support or testing at all; this includes major first party libraries such as ASP.NET and Entity Framework, you cannot use the latest on 4.8 full stop)
- Worse and more expensive tooling (8 can be entirely command line driven including locally and cheaper and easier CI/CD installs and scripts, has great support not just in expensive IDEs like Visual Studio or Rider but also [cheap as free] VS Code and through LSP tools even options like vim/neovim/emacs in ways that 4.8 has mostly never supported)
Yes, there's definitely a shift in LTS strategies with .NET 5+. It isn't tied to Windows support lifetimes anymore, which has benefits too (much easier to deploy new versions; I will never miss the days of "we can't use that feature because management keeps putting off the Windows upgrade migration"). It is using a very similar strategy to NodeJS of twice a year releases with "even releases" being LTS supported for two years. That certainly can sound like a more complicated maintenance burden, but faster release cycles and shorter support windows generally mean fewer backward compatibility breaks and an easier upgrade from version to version.
The way I see 4.8 "long term support": the VB6 runtime is still technically "supported" in Windows 11 for long-tail backward compatibility but such long "support" doesn't mean VB6 is a good option for writing code today for Windows (or has been for a decade or more), and the VB6 IDE and compiler have not been supported since Windows XP. Fortunately, 4.8 isn't the VB6 of .NET because there are clear and easy upgrade paths, plenty of good migration tools, plenty of good reasons to migrate (performance! cross-platform!), many developers have happily migrated with no intention of going back, many new developers to .NET have enviably never experienced .NET <5 for many good reasons (Linux support!), and .NET 5+ is still unarguably .NET in every way that matters (the languages are the same, a vast majority of the base class library is the same or distinguishably better). This isn't a hard fork at this point, this is much more clearly "present and most useful" versus "outdated and legacy". But the sentiment of "don't use VB6" is still there for 4.8: if you are still working on 4.8 this year you probably better have the excuse of a large "brownfield" application with a huge legacy footprint. You are probably going to have a bad time doing it, you are going to have an increasingly uphill battle to get new developers to go back to 4.8, and the IDE and tools for supporting 4.8 are going to lose support soon (the ones that haven't already) and will only get more expensive and rube goldberg-like, to be trapped in VMs of older Windows versions and increasingly network isolated because of that.
Just like their Xboxes.