RE: Clutch Virtual Ops: Consensus on the Second Layer

Regarding virtual operations on Hive: they are part of consensus code, so every node using the same version produces the same vops, but not part of consensus itself, which is the reason why they can be supplemented or changed retroactively (the latter actually causes some problems for apps that rely on them, but that is similar to API changes). It happens all the time. They are in fact a sophisticated form of logging, with the sole purpose being to provide users and applications data on effects of internal computations, so those computations don't have to be replicated outside.

Some simple example:
transfer_to_vesting_operation is followed by transfer_to_vesting_completed_operation virtual operation that contains information how much VESTs were added to target account - it could be calculated, but would require knowledge of price at the exact moment of that operation. For a lot of cases it is near impossible for external application to recreate all consensus calculations, with result of voting being probably most extreme case. There are also virtual operations generated when some automatic action takes place, like the power down steps you've mentioned. They tell not just the exact numbers but also time.

The fact that virtual operations are not part of consensus and therefore malleable is great for ease of development, but also can be a problem at times. See issue 448. I'm not going to repeat what I commented on the issue, just point the fact that EOS does close to what you've proposed - their "virtual operations" are not placed on blockchain, but merkle root of them is, which gives a level of confidence that they cannot be retroactively changed, which is important for example for exchanges that need to know if certain "virtual operations" they see in account history actually took place.