No doubt there.
This is a valid statement. I was coming from a perspective of doing these transformations on-the-fly per request. As of now the BB Oracle architecture would require on-the-fly mapping. The reason being that UTXOs need to be updated individually to change the spent state. Grouping UTXOs in storage would probably generate some overhead for sync times. Might be negligible though.
It’s just an optional metadata field. block_height or block_hash should suffice if the wallet does extra requests to get block meta data. timestamp seemed like an obvious use case. The optional fields are not very refined yet and just ideas I threw out there. None of these fields are technically required to spend the outputs which is why I put them in optional to begin with.
If included it does make sense to not have them repeated in every output and rather aggregate on a higher level.