Gazebo World Checkpoint: Plugin State Persistence Across Save/Load

Gazebo's world checkpointing feature serializes simulation state to a persistent file, capturing model poses, physics engine configurations, and SDF‑declared plugin parameters. The mechanism is documented for regression testing, CI reproducibility, and cross‑session pause/resume scenarios.

However, the serialization scope for plugin‑internal state remains ambiguous. Plugin code that stores state in C++ member variables not exposed through SDF may not be automatically captured during save, and its restoration during load is not guaranteed. Cross‑release compatibility hints suggest potential data loss when checkpoints migrate between major Gazebo versions, particularly after physics engine upgrades.

Does the save operation inspect plugin memory regions beyond SDF declarations? If the load service invokes user‑implemented System::Load callbacks, what assurances exist regarding the completeness of restored state? How does a major version transition affect the integrity of plugin state stored in checkpoint files?