While unsafe can be considered an effect, I don't see any reason to integrate it with the type system to the degree of throws and async. There's no practical reason for code to be polymorphic over unsafe-ness the way rethrows/reasync provide, or to try to capture an unsafe computation in some kind of monadic wrapper, or propagate unsafe-ness into function types beyond first-order declarations. Allowing that sort of abstraction also seems to me to be an anti-feature, since the purpose of these modifiers is to guide auditing, and abstraction gets in the way of understanding what code actually does, and composing unsafe code through high-level abstractions is a common way that C++ codebases become impenetrable. unsafe also has no ABI or representation impact on the code, so it can be freely added or removed to existing declarations. First order effect propagation is all we really need IMO.
I would also say that this wasn't really why we fixed the effect order. We only did so to avoid style wars and avoid the suggestion that async throws and throws async might mean different things. Effect "colors" are an unordered set, not a strict nesting like monadic wrappers are; you can do throws-only things or async-only things within an async throws function without having to "lift" or invert the computation through the other layer.