You may have a look at Quilt. I doesn't solve the problem the author described but may help you once you accept there is no easy solution in sight.
Quilt is automation for the "bag of patches" model. I used it once when I needed to upgrade the internal bag of patches at $big_corp so as to apply them to a newer version of $public_app. It was predictably complex but somehow still manageable.
If you squint a bit then the [bag of patches] + [automated application in order] is a poor man's Git. If you keep this in a git repo then you're basically versioning repos (poor man's ones) in a repo. It almost sounds like the solution to author's problem :)
Yeah, I mentioned Quilt in the post! Lappverk is effectively an exercise in "What if Quilt, but you could interact with it using any Git tooling, rather than Quilt's half-baked custom VCS?".
I haven't, no. But as far as I can tell from the documentation, it looks more like an alternative to stgit (with a similar lack of history or collaboration support)?
stgit is similar in that it sits with git, but it's not the same workflow. git-spice has branches per feature that base on one-another. It's more git-like than quilt-like.
What you get is git-styled patch-series development. Branches on branches where each branch maintains history of the feature.
A git-spice workflow is compatible with GitHub style PRs where a PR depends depends on another PR.
Or pair git-spice with format-patch you can share with developers who prefer patch files. Or take patches from someone and import each patch as a branch, then let git-spice track the stack position.
Quilt is automation for the "bag of patches" model. I used it once when I needed to upgrade the internal bag of patches at $big_corp so as to apply them to a newer version of $public_app. It was predictably complex but somehow still manageable.
If you squint a bit then the [bag of patches] + [automated application in order] is a poor man's Git. If you keep this in a git repo then you're basically versioning repos (poor man's ones) in a repo. It almost sounds like the solution to author's problem :)