Especially with servos that manually use TopLevelRunner, it is quite common for another experiment to start publishing a scan to the same dataset prefix as a previous completed scan. The applet should handle this cleanly and never show state with information from both runs mixed together.

See discussion in #381, where at least the source_id display was fixed, but which wasn't complete.

Not sure what the best marker of a new scan would be; perhaps something like ndscan_schema_revision. Separating things like that cleanly was a large part of my initial motivation for the server-side dataset namespacing. Without it, we might need to manually handle this in the subscriber code (such that the old data isn't used to get the schemata/points immediately after the refresh).

Another option would be to give up and accept that there might sometimes be mixed states. If the user explicitly specifies the same top-level runner dataset root from multiple experiments (can be multiple instances of the same experiment), there is nothing we can do to avoid the mess on the applet side anyway.

Does sipyco emits mods when datasets are set_dataset() from a new experiment, even if the value has not changed?

Then a clean solution would be to designate one dataset that takes the role of begininng a new scan (e.g. ndscan_schema_revision), and when this is observed in the subscriber code, chuck away all the current datasets and append the new datasets in only as they come in.

(The problem to avoid here is to avoid refreshing the scan after a new one has begun, but immediately load in all the new data that might still be present.)