It’s changing just information in a couple of vectors into another frame so its not decipherable if its “old” or “new”. The old is objectively wrong which was what was causing issues for non-axially mounted or 360 lidars.
I’d need to refamiliarize myself with boost serialization to know if we can tack on a new object with some metadata that we could use to pull out if new. The problem is since it wouldn’t exist in the old files at all, I’m not sure off of the top of my head if boost serialization will let me cleanly check for this and do something else instead. Even if it could, propagating that state through the SLAM Toolbox pipeline could become a real undertaking in it of itself.
I’m not going to say that this would be impossible to accomplish, but it is a bit more of an undertaking than I can commit to working out myself at this time due to purely time constraints.
Another option that would be probably much easier would be to have a bool to set whether you want old or new behavior, but it would default be off so that people got the fix. This feels almost to the point where just maintaining a parallel branch for the unfixed version would better for users though.