We have a base assumption that they would continue with the Firefox as own browser as an alternative. The most work has been already done. The assumption is that they would want to keep going with more privacy-friendly alternative that also try to avoid web standards that would be harmful for the end-user (tracking, specific kind of remote attestation, e.g.).

If they would fork Chromium, they likely want to redo the GUI. This is the easy part and that does not likely need upstream updates. That's what most forks do, and that is why they are maintainable.

However, if you start changing core, extension interface e.g., and if these browsers starts go different ways due to conflicts of interests, then the challenges and extra work start appearing.

Especially because of the security updates. Not all of them are CVEs, you need to look every possible bug fix if that introduced an additional issue if you used that part of the code differently. That must happen almost immediately as it is merged/notified in the upstream, or you might give too much time for someone to exploit it. The more different your fork is, the more challenging it is to get any update from the upstream. What if the upstream makes breaking internal API changes and you must adapt it, before you can merge new things. What if new CVEs are discovered after this API change that you are already lacking, and the fixed code goes for the code that has this API change? And so on.. and you can't stop merging upstream because reported bugs are much easier to exploit than discovering new ones from the new code.

The above is all extra work. You still want to test your own code. Even if you had more bugs in your own browser code, you have better control them and the process is always faster.