I ran into almost the same problem, with an almost exact use case, EPA's MS4 inspections. The solution, don't use UUID/GUID as the primary keys or have complex table relationships. This unfortunately complicated my reporting for the tables and created tables that could have normally been combined.
This is ESRI support's answer after they moved it to their engineers.
So, I've been able to get to the heart of the issue through the network traffic and we've ran into a bug that is a known limitation. I've attached it to this case and you can check it out on MyEsri but note that the bug is already closed due to it being a known limitation. The bug number is 000103223 and covers the following: "Hosted feature services in ArcGIS Online fail to edit a related table when the hosted feature service is related to more than one feature class."
Here is the explanation from development: "This is by design and a known limitation in ArcGIS Online. Users cannot reuse the same key for two different related classes. We are pushing the relationship to the database which is different than the enterprise which does all relationships in the client side with no validation. We have being advising our users to avoid this design."
The issue stems from the fact that GlobalID is being used by all of the relationship classes. The workaround would be to base the relationship classes on different fields from each other.
My solution to an AGO-only deployment was to use ObjectIDs. However, I could design it via my original relationships once I moved it to Enterprise.
I don't know if this is your exact solution but hopefully get you moving in the right direction. I spent a off-on month trying different tables, and troubleshooting the issue.