I have described exactly what is required for the thing to work,

Err, no, you haven't. You slightly suggested one possible thing, which has been tried by several languages, and found not to work. I'll reiterate my point, which I don't think you quite fully grasped the import of: A lot of languages have tried to implement asynchronous exceptions, and without any exception I'm aware of, they are either considered STRONGLY deprecated and kept only for backwards compatibility, or were even removed despite the impact on backwards compatibility. (Or, alternatively, they are just dangerous and the authors haven't yet realized they're too dangerous to keep.)

If you think this about an "FP" superiority thing, you're seeing a social fight where a technical one is taking place. Regardless of whether another paradigm can or can not do it, conventional imperative languages can not. You can't interrupt a conventional lock-based thread at an arbitrary location and then pick up the pieces afterwards in any safe manner. You especially can't do it when the "pick up the pieces" routine can itself be asynchronously interrupted. You also can't do it when it's not acceptable to just discard an asynchronous exception. The combination of all of these things has no known solution in an imperative, side-effecting environment. It's been tried by several languages, including even Java, point being not that that is the "ultimate language" or something but that they probably poured a lot of money into trying to make them work before they were forced to actually rip them out.

You are speaking as if you "know" that all sorts of languages ship with them and all I have to do is look at the existing safe implementations. They don't. You show me the conventional imperative language that has safe asynchronous exceptions, emphasis safe, not merely "use at your own risk". Be sure to check the documentation page you link me to very carefully for warnings like "don't really use this" or "the results of this call can not be guaranteed"... ideally the warning would be splattered in big type across the top of the page, but I'm going to find it even if it's been shuffled off to the side. And you'd better do a Google search on the feature too to make sure you don't find Stack Overflow or blog posts about how it's unsafe to actually use them, too, even if the documentation is mum or even directly claims they're safe.

Meet that, and I'll recant. No, seriously. This is an objective technical argument and if there is a conventional imperative language out there that has these, then I'm simply wrong. But I'm only slightly worried. I've actually spent some time jousting with this issue myself and I don't see how to do it in an environment with uncontrolled side effects. I just see a lot of things that look like they almost work, but then have another failure case, then the code that covers that looks like it ought to work, but it has another failure case, then you think that you can put a lock around the asynchrounous exception handler but you discover that causes async exceptions to potentially be dropped which limits their utility... there's a very well traveled path of "obvious" solutions that don't work.