I appreciate everything you just said and agree that this could work well for some people. On the other hand, reading it through the eyes of the 99% of people I know who can barely check their email, everything you said may as well be written in Klingon. It is simply too difficult for most people to understand.

It's not an unsolvable problem with good apps/software though. A key as a sequence of characters is confusing, but depicting an actual key cut in half, that needs to be combined with another, would make sense to people.

As was said elsewhere, a lot of this will come as the space matures.

Cryptography is a necessary lesson that we need to teach in 2017. Lowest common denominator is a hard threshold to design security for.

The attacker only needs to have compromised the device which spends from the wallet file

Only a half key exists in permanent storage on device. The other half paper key is loaded into memory for transaction signing, and then removed from memory the moment the transaction is sent off

You would need both halves to sign a transaction

I agree that you need "both halves" in this scenario to sign the transaction.

At some point during the spend from the wallet, the privkey that matches the wallet pubkey has to touch memory. This privkey can in theory be compromised in a number of ways with malware on the spending system (keylogger, screen caps, process memdump, etc).

I think the safest way to go about this is to generate an entirely new keypair/wallet on an isolated system. Spend from your wallet then transfer the balance to the newly created wallet. This minimizes losses as a result of privkey compromise (unless of course your isolated system isn't so secure)