Registering *.eth from L2 is hard problem to solve… it’s easy for sub/domain.eth and CCIP resolver on L1 with domain.eth pointing to L2 data resolver contract, people are already using that… I’d recommend not to introduce any breaking changes against stuffs that’s already working & if possible don’t add in extra complexity. ENS is already 3 levels deep with name registry, erc721 & erc1155 wrappers.
As we’re verifying manager/approved signature stored on L2/offchain, at worst case scenarios BAD L2 RPC/gateways can only send stale records… we could narrow down with extra ttl/validity timestamp but that’ll require manager/signer to update their records more frequently on L2/offchain.
In bad dapp/client scenarios they can resolve to anything even for non-ccip lookups… For current web2 gateway with signers, any BAD/compromised gateway signer can easily sign and send anything… Domain’s manager/approval sig is more trustless than web2 gateway signer.
There’s same old privacy risk with web2 ccip gateways. L2 RPC endpoints are still web2 but it’s less risky than random web2 gateways used by every domain.eth. Using CAIP22 like format can leverage L2/light clients if underlying dapps/wallet clients have light clients support in future.
“if clients are not following ENS specs they’re not ENS compliant…”, Paraphrasing @nick.eth’s reply from 2020 
back when I asked "what if bad scam clients skip normalization, or resolve their addr when I send $eth to “domain.eth” from their dapps/wallet.
For batch resolving I kinda preferred using @serenae’s draft specs [Draft] ENSIP-##: Off-chain Name Meta-Resolution [Draft] ENSIP-##: Off-chain Name Meta-Resolution compared to current ENSIP-16: Offchain metadata with extra “graphqlUrl”…
sorry I’m bit laggin… back to work! 