Today, you can do something like this:
Task { try? await someAsyncThrowingOperation() }
I just removed the use of detached here, for two reasons. First, in addition to not inheriting isolation, it doesn't inherit other context as well. But much more importantly, since the callee here is async, it doesn't really have any affect (unless an isolated parameter is involved, and in that case, is probably needed).
But I also do want to point out that there is yet another proposal pending that could influence this further.
With that in place, you could remove only isolation. Again, because someAsyncThrowingOperation is async and establishes its own isolation, I'm not sure this is actually useful for async functions, but I think it could be for synchronous ones.
Task { nonisolated in try? someSyncThrowingOperation() }
Now, in my opinion, using Task here is the best option. First, users of concurrency have to understand it regardless. Second, fire-and-forget operations don't actually come up that often, in my experience. And when they do, you usually have to think hard about them, so making them easier may not be an advantage. Finally, the concurrency system is already complex. Introducing a new keyword here would need a lot of justification.