The .NET Framework final version was 4.8, released IIRC sometime around late 2019.
.NET Core was out alongside the old framework for several years now and is on an annual release schedule:
.NET 5, Nov 2020, STS, 18 months support
.NET 6, Nov 2021, LTS, 3 years support
.NET 7, Nov 2022, STS, 18 months support
.NET 8, Nov 2023, LTS, 3 years support – in preview currently
This pattern is planned to repeat annually, so next long term service release would be .NET 10 in about Nov 2025, etc.
.NET Core is the generic name for the “new” runtime, which existed some years prior to .NET 5, so it is quite mature. The main purpose to rewrite the .NET runtime was a focus on performance and retiring technical debt. Prior to .NET 5 it was referred to as .NET Core 3.x I believe.
.NET Core is quite compatible with .NET Framework; the biggest departure is that the web framework has changed enough to break existing code. Under .NET framework 4.8 and earlier it was known as ASP.NET MVC 5, it is now known as ASP.NET MVC Core. Frankly I think they pulled a bit of a Perlman and renamed namespaces just to break things, but just a BIT of a Perlman. According to a colleague who would know better than I because he maintained the web site side of things at my old gig, it is not that bad once you figure it out.
Apart from that, I notice that the caching API has changed, and a couple of other small things, and there are a LOT of new functionality, such as [ReadOnly]Span, [ReadOnly]Memory classes, etc. Most people are claiming a 20% performance increase just for switching from 4.8/prior to .NET 7. My subjective experience bears this out (I’m unable to do formal comparison benchmarks as I no longer have access to the old system).
Another big change is that the VB.NET compiler has been sent to Microsoft India, where MSFT technologies go to slowly die, and they are investing everything into the C# compiler and toolchain, stating that the VB compiler will get no new features or other love to keep it on parity with C#. JetBrains and I think another smaller vendor have promised to retain a commitment to the VB world but you’d have to switch from Visual Studio to Ryder to get the benefit of that.
SO to your question – do you start the project on the old framework and convert down the road, or start with Core and “create workarounds for lower functionality”. I don’t understand the last phrase, the current runtime has the better functionality, it’s just that in a couple of areas it’s also different enough to break things but it is not a question of “duplicating” your work.
In my case I am rewriting in a cleanroom environment, entirely in C#, so there’s no real advantage to staying with the old framework, particularly since ASP.NET isn’t in the mix. It’s just a headless API, needing only a few administration tools which I can bang out in WinForms, which BTW seems to have a new lease on life as WPF seems to be getting the slow-motion heave-ho also.
The ONLY use case I would consider staying with the old framework is if you have an extensive finished / polished ASP.NET MVC 5 or earlier front-end that you want to just hit the ground running with for v1 (or something else deprecated like WPF or a sizable VB.NET code base). But I would build in a port to ASP.NET Core into my roadmap even then. It’s just a question of calculated technical debt.