I will clarify. For every block, given the set of transactions contained in that block, there are 2 potential hash values that are acceptable as the root hash. One of them represents the tree with the transactions applied to them. This case is checked first, because it's the least expensive for a client to do so. The second one represents the tree after it has been completely rebalanced. A client should have no problem determining which way it went simply by trying the first case, and then the second.
The problem here is that the full rebalancing operation requires everyone to run the rebalancing algorithm to even verify it was done correctly. This means it has to be optimized so that even weaker systems are able to do it. Otherwise, there's no point in including the simpler algorithm. However, if you do optimize it that way, then the point of having the simpler algorithm vanishes completely and the whole design ends up simpler by just having the full rebalance algorithm.