Pretty cool! One thing you should consider doing looking at using the pulldata("@geometry") on your features to get the full lat/long. That might eliminate your issue with trailing 0s. Another thing is to is set the type to 'hidden' or 'calculate' instead of 'text' for all of them. Then you'd want to use the bind::type and bind::esri:fieldType columns to set the type which will affect how the fields behave, including with calculations. bind::type will affect how the survey handles the particular field and bind::esri:fieldType will set the field type in the feature service, if publishing from scratch using Connect, or tell the survey what field type to expect if the survey is pointing to an existing hosted feature service.
We had a similar problem with marine mammal sighting data entry during in-water construction work. The Survey123 maps are clumsy and getting a user to accurately place an animal sighting on a map with no scale or bearing was very time consuming and took away from their jobs of watching for marine mammals. I've included a sample section of our marine mammal sightings form that takes the geopoint of the monitor's location using GPS and, based on the distance and bearing to the animal the monitor enters, it applies a calculation that creates a point in another geopoint field (has to be stored in a repeat) to place the animal's observed location. The cool thing is it is all done on the fly and if you type in an incorrect value, you can re-enter the correct one and it updates the second geopoint. I used the Destination point given distance and bearing from start point section outlined in this page to develop my calculation in Survey123.
I did have to set the bind::type and bind::esri:FieldType for the lat/long values to 'decimal' and 'esriFieldTypeDouble' respectively otherwise the calculations would come out wrong. Types matter and you might be able to consolidate your form a bit if the types are set properly and you can nest calculations that will work correctly.
