Seems fine I guess. I'm not a fan of Perforce but it does have some features that git still struggles with and needs to address to break into new customers. This Gitbutler seems to address some of them but I can't say it really feels next gen.
I like the idea of parallel branches. I feel like you could probably get away with just creating multiple, named stages but having a full history is nice. P4 has multiple pending CLs and it works nicely enough. This sounds a bit better so that's cool.
As far as "social coding" git's design is really at odds with any sort of real time communication. I would love to see a first class support for file locking, and file status work flows. It's not big at all in code dev because code can be merged but for non-coders, source controlled assets are often not mergeable. To solve this, P4 is often used with heavily integrated tools that provide live file status (Locked, out of date, edited by others). This way merge conflicts are prevented at author time. Git is really lacking here. Is fetching constantly really the best we can do?
Then of course... can we get some large file and partial checkout workflows that don't feel good?
Could you explain parallel branches vs what git offers today?
If it's to enable multi-agent scenarios, don't worktrees (at least in the local sense) allow for this?
My understanding is parallel branches allow multiple changelists to be applied to a single workspace. eg you can have multiple WIP fix branches active in your feature branch workspace and not worry about polluting your feature branch with unrelated/duplicated commits.
Worktrees are multiple workspaces, each in their own directory, sharing a single git repo. This is helpful because you reduce the overhead and the CLI command juggling for fully separate clones.
I have no idea what approach is better for your multi-agent scenario.