So Thread.Abort / Thread.Suspend are not just deprecated, they're removed outright from .NET Core, which I think is unnecessary.

.NET Core's nature is to power performance-critical online services, and for services, being "alive" is everything. A lot of efforts can be spent on making the service resilient against unexpected events.

.NET Core is also a very good embedding engine to power a plug-in like system (the service stays native, and extension code runs in .NET Core embedded in the host native service), it's not always realistic to expect that all code running on top of .NET Core to cooperatively check for cancellation tokens, nor would that completely eliminate the risk of "3rd party" extension code misbehaving.

Therefore, as a last resort, it's often required to do whatever is in the power of the service to stay live and being able to serve requests, even at the risk of having partially corrupted state and/or partially inconsistent state, for two reasons:

1. for a well-designed plug-in system, it can be designed so that any state the plug-in code can access & manipulate is per-request, so corruption to the state doesn't have global effects.
2. not every service is so sensitive to state corruption like database services, often times, arguments can be made that partially correct results can be better than no results.

That is, even if Thread.Abort can lead to inconsistent or corrupted state, it shouldn't be the reason to remove it all together from our toolbox.

We should trust service engineers' ability to weigh the risk against the benefit to make decision on their particular case, instead of worrying that they will shoot their foot somehow.

I think the extreme insistence on a "no corrupted state" program (hence the mindset "just crash if state is corrupted") doesn't apply well to today's service oriented world.

Bottom line is, without these two APIs, I have no way to stop suspected infinitely looping threads from eating up my cores and bring down my service's capacity, which is a big deal for services.