I meant to follow up on this article sooner when the details were fresher in my head but better late than never.
We completed additional testing and closer inspection on this measure precision issue on the NYSDOT Milepoint ALRS and confirmed the notes Nathan and Amit documented here. Specifically...
1. The Roads and Highways geoprocessing tools we tested, including Calculate Route Concurrency (CRC), generate results that respect the measure precision set in the LRS Network properties. (7 in our case)
2. We did eventually locate a series of very small geometry errors in the Centerline feature class, similar to what is shown in Amit's 6/2/21 post above. Once these errors were repaired in the ALRS, the small overlaps generated by the concurrency API and the Calculate Route Concurrencies (CRC) tool cleared up.
This issue turned up last spring while we were working on our "Roadway Data Mart" (RDM) which is being developed to publish the LRS network, events and dynamic segmentation results from NYSDOT's transactional Roads and Highways environment. One of the things we realized contributed to some confusion and concern is that a new field in the SQL Server 2016 geodatabase created by ArcGIS with type "Double" will create a "Number" field with Precision = 38 and Scale = 8. As a result, all the measure fields in our transactional ALRS are currently defined as Number 38,8
In the Roadway Data Mart (RDM), we wanted to completely avoid even the perception of a eighth significant digit right of the decimal point so we redefined all measure fields in the RDM to be Number 38, 7. We believe this will help mitigate potential data integrity issues related to measures when we use the RDM for both new dynamic segmentation products (ie. LRS event overlay results) and downstream system integrations.