Nice description of your situation. The one thing I'm unclear about is whether your team typically swarms a common problem together in a team-like fashion, or whether they split up and work on different pieces of work. Bugs tend to be somewhat isolated
from one another, or if related, can be handled together at the same time. But refactoring can cross many modules and be very disruptive to others.
Regarding the Branch by Code promotion strategy, you asked "once a codebase is promoted from Development to QA, can new development start in the Development branch and then FI to the QA branch?"
One of the tricky things about branch plans is that they interact with your process. If you hold the process constant, you can easily see which branch plan is better for you. If you are willing to reconsider your process, then you have more choices. This gives
you more room for creative design of the process and branch plan, but it is harder to contemplate.
From the manual
The Code Promotion branch plan will work well for your organization if you meet some of the following criteria:
1. You have a single major release that is running in production.
2. You have long running testing lifecycles.
3. You wish to match your branches to your various deployment environments (not required).
4. You want to avoid code freezes, and still have isolation for your planned release.
Your description seems to match items 1,2,4 perfectly. So this would be a good plan. In contrast, if all members are all working on highly coupled stuff, then it is better to swarm over the code together all at once and not split up the team. This latter model
would favor the basic branch plan more.
You see how the branch plan interacts with the process? Do you want everyone working on a single feature or maybe split the group in two and have one team nursing their product thru QA while the other team is doing basic development of the next feature?
The "Branch by Feature" plan supports even more fragmentation in your development effort. But it aggravates the challenges that come with multiple branches.
If you have refactoring to do that could be very disruptive, then you will benefit from something like Code promotion branch plan, where part of your team can nurse the release thru QA and onto Production while someone else does radical refactoring in Dev.
Just make sure that the teams in QA and Prod only make the most essential and minor changes. You don't want two ambitious changes going on in parallel. That would make merging a headache. Imagine how disruptive it would be if a developer in the QA branch decides
to start a new refactoring there. Then when they go to reverse-integrate, they disrupt the dev team in the dev branch. You should only promote it when it passes your quality checks and code reviews, just as your process describes.
And remember, you can try out one branch plan and then change later if it does not work well. But remember to keep an eye on the dance between process and branch plan. If it is not working, you can also ask "Should we divide up the work differently? Should
we encourage more or less collaboration?" These changes are just as much fair game as the branch plan.