I'm not sure why you're being down voted, but this is a very reasonable counter point.
The purpose or brief should be at the top of every file, it should also evolve as class or implementation does. Arguable that it's really the only one that matters and can also come from no other tool or location.
Right, that is being spun off and no longer with HPE. Figured the example being sought was software that will no longer be with HPE and not just this specific spin off.
For me personally having a history in this space these are two 1.0 features if releasing today. Back when they released 1.0 it might not have been obvious that these features were needed to differentiate.
But getting the single threaded path solid before adding parallelism is a good choice.
Do you really need to protect the entire system? Or have you not captured the setup of your system in a provisioning tool like ansible or chef or the like? And then protect only the necessary files to restore the configuration and user data of the system.
Protecting the entire system should be something that is done near line so if you have a catastrophic loss your time to recovery is less than that if everything was stored somewhere in the cloud. Or Just not do it at all and rely on a tool manage the configuration of your system.
Data files and configuration are really the best thing to protect with a tool like this. If you have a total loss your playbook should include something like replacing the failed hardware, Installing and patching the OS, replaying configuration of the system using ansible or chef, restoring data files.
To me this is the fundamental gap that cloud backup solutions need to fill to really capture the consumer market well. The SMB market already has this as you goto IT and get your system reloaded and then restore your user data, its pretty much the standard for larger corps.