Ah, I see. Yeah, the relationship between parent workflow profiles is not relevant to locking, only the relationship between base child profiles (Import, Forms, etc) and their direct parent. This is because the philosophy of the product is that data is entered strictly in base input profiles, so their locking status is the only one that really matters. Overview profiles are effectively independent.
You can see it demonstrated in the image below.
The children of QuebecLoad are locked; if I then locked QuebecLoad, I wouldn't be able to individually unlock Forms or Import Montreal TB, because their relationship is enforced for locking purposes. The relationship between QuebecLoad and GlobalSRVReview, on the other hand, is not considered, so both can be freely locked or unlocked regardless of each other's status.
If you need to enforce locking logic between parent profiles, you will have to add an Event Handler that checks whether locking or unlocking operations are allowed on the given profile. You will need a bit of coding for that. An alternative is to restructure your profiles with the above logic in mind, and/or using Named Dependants.
On a Review profile, in the Default scenario type, you can set up your Named Dependents:
"A property on a Review Profile that allows it to be responsible for workflow profiles that do not directly roll up under this profile's hierarchy. This is commonly seen with Shared Services".
I'm confident they're mentioned in training material in Navigator.
Unfortunately I can't provide BR code for the event handler strategy but I know it's doable.
