If you try to load a CellProfiler pipeline from a later version of CellProfiler than you're running (ie, you're running 4.2.5 and you get a 4.2.6 pipeline), CellProfiler warns you that it may fail or otherwise give unexpected behavior but otherwise lets you do it. This is I think reasonable default behavior.

We last week though ran into an issue that we had to troubleshoot that a given module had changed so much it was a different version, and so the settings were passed in out-of-order and it gave weird results. This was in the context of a plugin, but I'm not sure that matters for the statement below.

If a module has actually changed versions, it's usually not just that we've patched a bug, we've typically changed functionality substantially. Unexpected behavior is therefore then not just possible, but very highly probable. Should we therefore catch and never try to process module versions > the module CellProfiler knows about?

• Arguments for: easier to troubleshoot "Could not load Module X, pipeline version of Module X is 4 and current CellProfiler version is 3, this module is not supported" than "Module X could not load {some string setting} with {some int value}"; module behavior is likely different if we bumped the version numbers. We don't officially ever guarantee backwards compatibility.
• Argument against: When we DO add new settings/behavior, we usually are very careful outside of major version bumps to make sure the default upgrade_settings path recreates the previous behavior. So you can very easily imagine a case where, if the new settings are always added to the end (which they don't have to be, but is good practice we try to instill), a user goes from 4.2.5 to 4.2.6 with a pipeline, where Module X has officially a version bump but not behavior change due to upgrade_settings being a bro, then takes the pipeline BACK to 4.2.5 to ie run it on their home instead of their work computer - with the current behavior, this will just work without them thinking about it I'm reasonably sure (CellProfiler will just ignore the "extra" settings at the end), but we'd fail to execute it and make life harder for the user if we did refuse to load Module X.