As explained in http://lists.llvm.org/pipermail/cfe-dev/2018-May/058055.html, findDirectConstructorForCurrentCFGElement() was not working correctly in the current example and erroneously made us think that we've constructed into a dummy temporary region rather than into the variable. Instead, it was proposed to track it in the program state every time we are performing construction correctly.
Additionally this information will be used to maintain liveness of the variable's Store bindings, because previously an incorrect Environment binding of the target region to the construct-expression was used for that purpose. Such binding is incorrect because the constructor is a prvalue of an object type and should therefore have a NonLoc representing its symbolic value. Therefore the hack implemented by isTemporaryPRValue() can be safely removed.
findDirectConstructorForCurrentCFGElement() cannot be removed yet because it is also used for constructor member initializers for the same purpose. It doesn't seem to introduce bugs though.