It's not just change. It's difficult to make it work for a single version. It was difficult back when the build tools were a handful of powershell scripts. It was difficult when they moved to the dotnet tooling.

Microsoft shouldn't push out an RTM product and call the broken bits "Preview" to absolve themselves of the responsibility to deliver a reliable product.

I was evangelical about .NET Core. I stuck with it for years. I stuck with it when Damian admitted that he "doesn't build web apps". I stuck with it during the Release Candidates. It's only when they pushed this out the door and called it RTM that the penny dropped and I accepted the project had been mismanaged.

They announced all of this before .NET Core went RTM. Not only that, the tooling was never made RTM (still in preview). If you jumped on the bandwagon that early then you had all of this information and knew what was coming.

You should just wait until both the framework and tooling are RTM if that's the stability you need - the framework is already great but if you need the tooling then wait until it's ready.

Why complain if you understood the status and assumed the risk?

Microsoft have always had extremely stable RCs.

If you knew anything of the traditional release history for Microsoft you wouldn't have commented. All your post demonstrates is total ignorance of the context or history.

It was previously totally fine to use RCs for the last decade, probably way before that too, but I only have experience from then. RC in MS speak meant "pretty much finished, API won't change unless we find something desperately wrong".

Then it suddenly means basically pre-alpha, "anything can change, massively, between RC versions".

Great, it's still RC vs RTM. Past history doesn't mean forever. This is still your interpretation of what an RC means getting you into trouble.