Only complex for developers. The actual need is that translators start translating one form then later realize that they need another form and be able to specify for which case/number they want to specialize a variant.
The interface can then propose a "detailled" view summarizing how the various forms are mapped, including their fallback. Translators can then just click and confirm the proposed fallbacks or copy-paste another existing translated form for the same base resource.
All forms should be grouped and a si,ple view could just list those that are different; and summarize the list of cases/numbers to which they apply.
Internally the fallback mappings is part of the support code, and translators won't have to focus on it.
And in the simplest case, they'll start by translating the default plural rule ("other" in CLDR) for used for undetermined numbers and the nominative case (or the effective case when translating full sentences).
The internal Gettext numbering of forms (plural, case...) is technical and should not be exposed to translators but they should have a clear labelling of these cases and possible test cases for various numbers in the detailed view. Adding variant forms should remain optional and should not impact the language fallbacks (language fallbacks should never be used as soon as there's the default "other" form translated).