This is a very promising idea! I think the managementEoa can be a smart contract as well, since smart contracts have nonces too. So I would change it to:
keccak256(MAGIC || chainId || nonceManagerAddress || nonceManagerNonce || invokerAddress || commit)
In fact, I’d imagine that the nonceManagerAddress being a smart contract would be more useful, since then the EOA can just “own” the smart contract as opposed to having to guard a separate key.
The nonce manager can even be deployed lazily — its address can be computed deterministically from a well-known factory. That way, EOA users can use nonce managers without paying for the cost of deployment, and a lot of EOA users probably won’t ever deploy any nonce managers if they don’t ever have to resort to global revocation.