


They could easily write you a script that could batch process old files (find old files, search for dirty ops inside them and rebuild any that it finds, then save the file and generate a report of the files and operations that had toolpaths needing to be rebuilt), you could then open the file and quickly review those operations. I guess if the regeneration of these toolpaths is taking too much time it could be frustrating but this is where your reseller could help out. The only downside of the ops being marked dirty is the time needed to rebuild. Making changes to a toolpath and not letting the end user know which ops may be effected, now that would be dangerous.

Sure, eventually when you do open the file you'll have to address those toolpaths but I don't think that's a bad thing. If you posted out gcode last year and no processes have been changed, why not just run the code that was used previously? I think the easy solution for you is to not repost code if you are not making changes to it.
