This is a common scenario. When dealing with a breaking change*, like this might be (see below), there are three approaches to handling it.

The platform today supports deprecation (“deprecation” meaning the actual platform feature of that name, not in the generic sense of the term) only at the integration-version level, not at the trigger/action level, or at the field level.  

1. Mark the trigger or action as hidden, and create a new one. Users setting up new Zaps will only see the new set of fields. Pro: Existing Zaps keep running.  Con: You end up with users stretched across lots of old, invisible trigger/actions - and you might tend to forget about them and allow them to fall into disrepair.
2. Make the breaking change, promote it, but don’t migrate existing users to it.  Similar to the other approach, existing Zaps don’t notice a change, new Zap configurers will only see your new input form.  Use semvar in your version numbering to note that the new version represents a breaking change. Users can keep using the old version forever, or as long as you choose to maintain it.  Downside is you end up with users stretched across versions, and stuck on old code lines where they won’t have access to new features you add, unless you end up doing something like maintaining separate 1.x.x and 2.x.x code lines - which is overkill for a small change like this. 
3. Building on top of option 2, when you need users to stop using the old version, you can mark it as deprecated.  This will send an email to all the users of that version letting them know they need to revisit the editor reconfigure it. If they haven’t updated by the deprecate date you set, their Zaps will be disabled until they go it and make the the changes. it’s pretty severe and goes against the set-it-and-forget-it user experience of Zapier, but sometimes it’s necessary, like when the underlying version of the API itself is being deprecated. TLDR use this option sparingly and not too frequently.

*That said, I say this might be a breaking change, because technically I suspect, if you coded carefully, you might be able to just migrate users from ver x to ver y without issue (i.e. not a breaking change). If the input value was really no longer relevant to the request being made, and you removed all references to it in your trigger/action configuration and code, the platform, I think, would just ignore the extraneous input mapping from the Zap definition.

To test this (which is the only way to be confident here), set up a Zap or Zaps with the old version under your account or a teammate’s. Go into the version management tools and use migrate by email to migrate those Zaps to the new version.  Then test them and make sure they are still running properly (watch task history, and verify Zap behavior in the apps themselves).  if they work correctly then you’ve avoided a breaking change.

Thank-you for the comprehensive reply.

Over the weekend I did a test which unfortunately proved our proposed changes would break current Zaps.

Option 1 seems more desirable but requires alterations to our current implementation architecture to minimize divergent code paths.

Appreciate your time and input.