Thanks for the feedback, @areyus.
Backward compatibility is exactly the kind of thing we should weigh here,
so I appreciate you raising it.
Let me start with what I think is the most important point: #10926 has only been merged into develop — it isn’t part of any GA release yet (Foreman 5.0 is currently scheduled for 2026-09-08). So the strip behavior, where you can put CIDR notation into the address field, is a new behavior that hasn’t shipped in any stable release. There shouldn’t be any production setups depending on it yet.
Because of that, if we settle the direction now, while it’s still on develop, we can decide this before anyone comes to rely on the new strip behavior — which avoids the very “breaking existing workflows” scenario you’re worried about. If anything, changing it after it’s gone GA is what would actually introduce that incompatibility.
On timing: the 5.0 schedule has branching on 2026-08-11, so if we want this decision to make it into 5.0, that’s effectively the deadline. That’s part of why I’d like to nail down the direction now.
As for (c), I do see its advantage for backward compatibility, and your framing — error out on conflicting/invalid input, but keep the current behavior when the input is actually valid — makes sense to me. That said, to be honest, since we’re still pre-GA and nothing depends on the strip behavior yet, this feels like a good opportunity to go with the simpler shape of (a) while we can.