Thanks all for the suggestions. After a lot of testing, I've arrived at the conclusion that this behavior is a result of having relationship classes not based on globalid/parentglobalid.
I tested the following:
-Created brand new survey using original survey's template, and published to new feature service > Successfully edited features with correct attributes; no errors. (Thanks to @DavidSolari for that idea!) I also investigated the schemas and relationship classes. The relationship type was "Composite" where mine was "Simple", and I tested both of those, which didn't seem to make a difference.
-Renamed "parentGobalID" to "parentglobalid" in first related table > Didn't seem to change any behavior by itself
-Removed second related table from original layer (the one that wasn't working) and re-published > That removed the erroneous behavior and everything worked.
-Kept the second related table but removed the "parentglobalid" attribute, and left the relationship class using Project_Number attribute > this caused the same problems (I thought it may just have been having the "parentglobalid" field present, but I guess not)
Even though it worked when I created a new survey from scratch, including a point layer with a related table and another table related to that one, both using globalid/parentglobalid for the relationship, that format won't actually work with my data. My data is structured so that the point layer represents a feature, the first related table is a work item performed on that feature, and the second related table is a list of all projects that all work items were done under. So, Point A could have 2 work items -- Inventory, Repair -- performed under 2 different projects, and Point B could have 2 work items also -- Inventory, Replace, but the Inventory item could also have been done under the same project as Point A. So 2 features in the first related table point to the same feature in the second related table. This works well for things like pop-ups, where I can show relationships between features, different work item types, and projects (I'm using Arcade to show a list in the pop-up of all projects a feature has had work done under), but it means that I can't create a one-to-many relationship between the first and second related tables. Hopefully the illustration below helps.
Point A --> Inventory --> Project 1
--> Repair --> Project 2
Point B --> Inventory --> Project 1
--> Replace --> Project 3
I was hoping to be able to make this survey so it only edits the point layer and the first related table, and maybe settle for making a different survey altogether for the second related table, but currently, even having the relationship between the first and second is causing it to break, so that's currently not feasible.
@DougBrowning, you mentioned that you've done this where you've had multiple related tables using different key fields, and it's worked in the past? If that's the case, then this may just be a bug in the latest version.
