I'm a non-bitcoin related developer that has held an interest in the technology for a long time, but there's a couple of observations I wanted to make.

First, my observation is that BU has forked their code from an ancient version of BC and have changed things including needlessly renaming variables to the point that a merge or cherrypick is literally impossible. As a result the efforts of BC, ahead by roughly 4000 commits, cannot be pulled into BU. As a result there is no real sharing of effort. The reverse is somewhat true as well.

This to me raises huge red flags as it means all the upstream fixes do not make it downstream and it seems to me that the tests performed by BC are far more extensive and measured than those by BU. This immediately shows a maturity in the code design to me. If I were downstream I would take advantage of all that work and just add my bits on top.

As a backend developer myself, I am quite used to the frontend guys rushing ahead trying to slip features through that break security or avoid proper tests and getting annoyed at me for 'holding them back'. Its my job to ensure that everyone who links to my stuff follows the rules, has full integration and unit tests. This can be aggregating to others but it results in better code. It also requires lots of stubbornness on my part. I'm sure those of you in similar positions will empathise.

There are a significant amount of people invested into BU for one reason or another. My fear is that whilst the intent may be good the code is not mature enough. We also have Core who have their own path, right or wrong, that many others are heavily invested in.

Why not have a fork of the latest BC, that merely adds the large block support in, and tracks closely to upstream. This way you have an implementation that has ALL the benefits of BC, ALL the tests and measured pace, and you can just test the bits YOU want in on top. This will greatly help BOTH sets of developers as you're looking at similar code and problems in one can be fixed in both. It means that whilst a competing fork may not agree to the same rules, the developers time on that competing fork time is NOT wasted and should the fork die at least their time looking at the same code could potentially fix or improve the other fork AND garner them experience to potentially provide support to the winning fork. If the fork wins, the same is true of the other developers.

By having two totally divergent forks that do not track each other we have enormous waste of work should one fork die. This I think is tragic.

Example: BU wants large blocks and no segwit. So track BC closely, include all the code that includes segwit, add the large block support (and test this extensively) but disable signalling for segwit. Track upstream changes to segwit (but have it not signalled) just in case it wins. If it fails, then both chains can just pull it out entirely. If it wins, the losing chain just switches it on and moves to their next goal.