Maybe we are conflicted about what you mean by 'working set size'? When one is validating, the witness data is part of the data you are working with, right? (duh - otherwise there would be nothing to validate against). Accordingly, is it not part of the 'working set'? Are are we dealing with an arcane ephemeral definition-of-passion?
So again I ask: How, pray tell, does one validate a transaction, if one does not possess the signature data?
Maybe you noticed when you sync full node from zero, it goes fast first and only last months take so long to finish. The reason for this is until last checkpoint, no signature data for transactions is ever validated. Thus you dont need old witness data to sync until last checkpoint. Only after the last checkpoint is reached, signature data for transactions is validated and so witness data is required as well.
Yes - this is yet one other 'enhancement' added during the elaboration of the QT client. However, this change is a fundamental violation of the trust model. In and of itself, such a change to the trust model is nothing to balk at. Indeed, it does bring concrete benefits to several use cases.
The Sin, however, is in claiming that using this client allows one to use Bitcoin in a trustless manner. If one does not validate all transactions from t=0, then one is outsourcing the chain of custody to others. Others that you must trust.
This change should have been advertised far, wide, and loudly to have contained this tradeoff.
Basically SegWit helps syncing new full nodes, althought MUCH better performance would be if you just downloaded latest UTXO set and started syncing from this point.
WTF did any of the validation-skipping done for several versions of the client have to do with your statement about SegWit?
With that out of the way...
So again I ask: How, pray tell, does one validate a transaction, if one does not possess the signature data?