There are too many comments for me to review all of them fully to determine where you are but here's what's wrong with the basics. If you fix these things, you should be able to move forward.
1. There is no Referential Integrity enforced. If there were, you would be getting errors that would have pointed out some of the other issues. If you cannot add RI, then fix the data FIRST and go back and add RI.
2. Foreign keys should be set to required if a value is required. None of the FK's are defined as required.
3. Foreign keys should rarely have a default. The default should normally be null. The default should NEVER be 0 since that isn't a value that would ever be generated as an AutoNumber. For example, it might make sense to default the ProjectPhaseID to "1" or whatever the first phase is but by what logic would you default the engineer to "1"? Personally, I don't think either of these fields should have a default at all. DateCreated can default to Date() if that makes sense but if you are always entering data after the fact, then even the date shouldn't have a default but all should still be set as required.
4. You have default values set on the form controls so the length will NEVER be zero and that means that your validation will never work.
I'm pretty sure I made some suggestions earlier in this thread but you chose another path. I'm going to explain again the issue.
You cannot save a child record that has no parent record if RI is enforced (you do not have RI enforced but you should). The forms also raise errors if you try to do this as long as the master/child links are defined since the PK of the parent record would be null if no record existed so this essentially prevents you from creating a child record without a parent. Not that you would EVER want to do this in any event. However, Once the parent record is saved, there is no built in way to force you to save a child record at this time. The reason for this is because relational database theory does not require it. So if the basic definition of a relational database does not require something, neither Access nor any other database engine will enforce this rule. This is a business rule and you are solely responsible for enforcing business rules. You were told multiple times that the only way to actually do this is by using unbound forms or forms bound to temp tables. Only when the entire transaction is complete would your code attempt to add the data to the permanent tables and this code would run inside a transaction to ensure that BOTH the parent and child rows got copied. The transaction ensures that ALL actions within the transaction have completed successfully before any are actually committed.
One other thing that needs mentioning is with regard to how bound forms actually work. Somewhere in this epic thread you or someone mentioned that you want to make the subform dirty while the mainform is dirty. That is NOT possible. When you move focus to the subform in order to dirty it, that forces Access to save the main form first. So the main form is saved if it is dirty and THEN the subform gets the focus but the main form has ALREADY been saved so it is no longer dirty.
You are creating a logical impasse. You can't save the child record when the parent has not been saved (RDBMS rule) and you can't save the parent record when there is no child record (your business rule). Something has to give.
You have spent a long time fighting with this but I'm not sure you understand what the battle is all about yet. This isn't a failing of Access is is a conflict caused by your business rules. So, step back and answer the question - what bad thing will happen if there is no location record for a project? If the answer is nothing, then fix the problems I identified and move on. Stop trying to enforce this business rule.
If the world will come to an end if a project is created without a location, then you will have to create shadow tables and all your create activity will have to happen on the shadow tables (this will be a far easier solution to implement than unbound forms would be. But there are still lots of moving parts). When the user wants to commit his work, he presses a button and your code will verify that there has been at least one location created. Start a transaction and run two append queries. One that appends the project and the second that appends the location records. Don't forget that you MUST obtain the Autonumber PK of the project record BEFORE you can run the append query for the locations so you can pass the FK to the append query. Then you delete the project from the shadow tables and complete the transaction. ALL I/O that took place within the transaction will either complete successfully or be rolled back. You'll have to figure out how to deal with errors. In addition, since "adds" are essentially done off-line, you will need application logic to bring up pending "adds" that have not been completed and deal with them.
You will also need logic in the view/change/delete version of the forms to prevent the deletion of the "last" location since that would create the anomaly of a project without a location.
Another solution I have used multiple times is to add a flag to the parent record. When the set of data has been verified, the flag gets set to "verified". So, your form would have a "verify" button and that button would determine if there is at least one location record and if one was found (use dCount()), then update the verified flag to true. This is significantly simpler than the shadow tables solution or the unbound forms solution. However, noting is without problems. This solution is difficult to add to an existing application because you will need to find all queries that reference the project table and add criteria to ignore any unverified records. EXCEPT of course for the maintenance form. That form needs to include the unverified records in order to verify them. Keep in mind that once the project record is saved NOTHING IN THE WORLD can force the location to be saved. The user always has access to the power off button and will use it if frustrated. So, that means that this technique as well as the shadow tables technique REQUIRES that you run queries at startup to identify work in process and bring it to the attention of the manager as well as the person who started the task but didn't finish it.