Automatic Transaction Representation

Would it be better to be categorized like EIP-712 (EIP-712: Typed structured data hashing and signing), as Standards Track: Interface but not ERC?

I thought so as well, but the majority of other editors disagreed.

If the transaction originates from an embedded frame (e.g. an iframe or webview), the wallet MUST […] add a warning that the request may not be trustworthy

This seems too strict. If the wallet can determine the embedded frame is safe (maybe same domain, or similar rules), it shouldn’t have to display the warning. I’d change this to a SHOULD?

If the request references a contract that doesn’t have verified source code […]

This is a huge centralization risk. If every wallet implementing this proposal has to somehow implement contract source validation, they either need to include an entire IPFS client and a dozen solidity compilers, or rely on a centralized provider like etherscan.

Somehow only just now got the notifications?! I have updated the EIP.

For the contract source and audit requirements, how do you handle differences in execution between simulation in the wallet and what actually happens on chain?

A verified source contract can pretty easily call into a non-verified contract, and an incorrect “verified” stamp is worse than no stamp at all.