But note that the post you're referring to from the developer forums seems to be mistaken: a strong reference is needed to call the modify() function
The modify function is never called in that post.
the asynced block will also capture a strong reference to self and hold it until after the block is executed
From your second statement, the async block captures a strong reference and the value is being modified in the async block. Which means that modify IS using that strong reference. And you can see in my example that replacing that with [weak self] also leads to crash.
You have a test case that only seems to crash in Playgrounds. I do not see any problem in your test case's use of queues. My guess is that Jordan is right and this is just a race in how Playgrounds collects values. I'm not sure that Playgrounds expects to have to handle concurrency within the script.
You also have code that crashes in production. You've drawn a connection that they both involve enums, but that's a very weak connection, like saying that they both involve structs. It does not make any sense that enums would have some special bug introducing races, because enums are value types and do not rely on shared mutable memory behind the scenes. It is much more likely that your production code simply has a race in it which your test case doesn't.