What is the value of actually merging the Yii branch into master?  Isn't another option to re-name the master branch "1.92", and rename the Yii branch "2.0", and instructing people to commit to the 2.0 branch instead of 1.92?

The reason I ask is I'm trying to picture how debugging might be affected after such a merge:
(1) In many cases, we have identical commit messages for Yii and master.  Will it be easy to search the logs for the Yii vs. 1.92 commits for a particular bug and checkout the right code (e.g. the version right before that fix)?  I guess it will be obvious if we've checked out Yii instead of 1.92 (since the code organization is different), but that sounds like a it of a pain and trial and error to get the right version, especially if you need to step back through several code iterations
(2) Would that affect the ability to use the git commands that let you find the source of an error (the ones where you write a test case, and you tell git that the error happened sometimes in the last 6 months, and it iteratively checks out code, runs the test, and keeps splitting the difference until it finds the earliest code where the test fails)?
(3) If we found we needed to make a high priority fix to 1.92 and to 2.0, would that be harder after merging the 1.92 and Yii branches?  Seems you'd need to checkout the final 1.92 branch, make the changes - but then commit them to which branch?  At that point, committing to master wouldn't make sense, since master would be based upon Yii, so you'd need to maintain a newly created 1.92plus branch for the critical fix, in which case, why bother merging Yii into 1.92 in the first place.

So, I'm not convinced that merging Yii into master gains us anything; and it seems to risk making maintenance considerably harder.

Instead, can we just rename the branches and/or simply instruct authors to only commit to the 2.x branches?