1.) I'm going to have to change part of the interface to mapping support again to accommodate another change in the user interface. We are in the _coding_and_testing_ phase folks, this is not the time to be making changes.
2.) There is currently no way to get information about the existing data from a field. I can get a field ID, I can request information about data associated with a field once I have the tag ID for that item, but there is no way of getting a list of the items that are associated with a field. That's a pretty big oversight since it's KEY TO THE OPERATION OF THE WHOLE SYSTEM.
3.) With the current method that is set up for common setup/data rules, there is no way to tell the difference between a change in the field (requiring a full invalidation of all data associated with that field) and a change in a single data element not associated with the field in any way. That meansd that any small change will cause a wipe-and-restore of all of the data in a field. Every time.
4.) Interchangeable use of the terms "track spacing" and "working width". They aren't the same thing, but they atre being treated the same in the system. This is gonna bite somebody in the ass a year from now, but it won't be me.
5.) Documentation out of date. Like the message types document.
6.) IPC Data objects and the associated complexity. There is no good reason that I have to create an object every 200 milliseconds and attach it to your data just to find out whether you are sending me a yes or no response.
7.) Units. Why is it necessary to create a units system that is capable of every possible conversion that may ever exist? We can divide up the units into linear measurements, velocity measurements, volume measurements, rate measurements, etc. We don't need to combine them. We don't have a need to measure liters per furlong per fortnight.