Inevitably, in the case of a "civil war" (to use Nick Szabo's words) where we have surviving, competing blockchains, wallets will need to be able to distinguish between inputs that were created before and after the hard fork (and if created after the fork, to which fork they belong).
While I first dismissed your comment because it was related to a post-fork situation while I tried to discuss pre-fork mechanisms, I do think now that the approach you described may work pretty well to supplement what I suggested. I will try to explain:
0. Developers threaten with a fork because of disagreement over block sizes and use block version numbers to coordinate it.
1. There are now both users who see more merit in small blocks, and users who see more merit in large blocks. Because miners pushing towards the disfavoured option contribute towards an expected future risk of having to deal with the disfavoured block size, those who accept BTC start to refuse accepting BTC coming from the coinbase transaction of a block that chose the disfavoured option, or at least to charge more BTC in this case in order to hedge the risk.
2. Business between small block proponents and large block proponents becomes more difficult.
3. Now, the fork happens, but in step 2, the business relationships have already evolved towards mostly being between proponents of the same block size, so the fork is less disruptive (it essentially only destroys the possibility of moving coins between small-blockers and large-blockers.
Step 0 is what we have.
Step 1 is what I suggested when starting the thread.
Step 3 is the post-fork situation where it became unavoidable to distinguish between the different forked chains.