We can compare Pallet transactions to XCM transactions:
Pallet transactions:
- Meaning determined by pallet and runtime authors.
- Meaning can change with every upgrade of the chain; no limitation in frequency.
- Unversioned.
XCM transactions:
- Meaning determined through RFC process and community input.
- Meaning changes only when a new XCM version is arrived at (historically once per year).
- Versioned.
Constructing XCM transactions therefore seems like it is much more suited to offline devices which need to determine/display human-readable semantics. The signing device would still need to be updated when a new version of XCM is released with that new XCM documentation, but this is extremely infrequent and certainly no more often than once per quarter. XCM is designed to be highly composable and flexible - substantially more so than pallet calls. Complex de-fi operations involving multiple steps such as withdrawal, borrowing and exchanges are in fact better suited to a programmable environment like XCM than they are to regular Pallet calls and there are already some planned features which will make this stuff easy to express in XCM.
The Pallet metadata approach would still be needed for chain features which XCM cannot express. The Merklised metadata approach which @lucasvo pointed out above is the way to go; the chain would both include and sign transactions with the current metadata hash. Hot UIs can then append the relevant metadata together with proofs that they correspond to the given hash in the transaction payload given to the signing device. This new format of transactions could even co-exist with the older format, allowing the metadata signing to be optional (though offline devices would obviously refuse to sign if not included). This ensures that it is possible to make transactions which are desired to hang around over runtime-upgrade boundaries.