I appreciate the effort here, but in the proposed workflow are missed steps with subscribing to a mailing list. Without proper subscriptions and confirming subscription, your mails with patches will go to trash.
> Configuring git send-email is trivial, definitively faster than creating an account at some web UI from a "source forge" <snipped>.
You forgot that mailing list requires subscription and in some cases it could be a tricky. Without proper subscriptions and confirming subscription, your mails with patches will go to trash.
The main scenario is live migration of containers. We have live migration feature in OpenVZ since 2005. But it was always in-kernel implementation of checkpointing Linux processes (https://openvz.org/Checkpointing_internals). Linux kernel developers won't accept our patches to vanilla and we decided to implement C/R in userspace.
Others scenarios are here https://criu.org/Usage_scenarios
https://github.com/kedder/ofxstatement