Later in the discussion Peter assured me that the release managers' job would be to manually select which commits to master are problematic ones and exclude
Andrey Semashev wrote: them from the Boost release. This sounds like a tedious task to me, but it would remove the delay in the Boost release at least. It's not necessarily tedious because manual intervention would only be required in the cases in which there is a conflict. In this approach, the develop branch of the superproject will be scripted to always point to the tip of the master branches of the library repositories, whereas, per gitflow, the master branch of the superproject will point to the latest release. A new release would be done on a release branch (again, per gitflow) which initially starts from boostorg:develop and, if there are no issues, gets merged into boostorg:master. Reverting boostorg:develop commits on the release branch will only be needed in the rare cases in which a library needs to be rolled back. (It's also possible for boostorg to have a scripted branch, say "latest", which points to "develop" in all libraries, but it would play no role for the releases.) This is, of course, not the only option. It's just one way of doing things.
But still it doesn't help individual developers since their tests would be broken for longer times and integration problems not detected early.
As I said, it's a tradeoff. If your library depends on many other libraries, some of which tend to often be broken on their develop branch, you would prefer to test your library against their master branches, since these would hopefully be less broken. This allows you to proceed with your own tests without waiting for the dependencies to clean up their acts.