A shared networking module has grown to 60 input variables, many of them feature flags, because every team asked for its own option. Upgrades now regularly break someone, and new users cannot tell which inputs matter. What is the best way to evolve the design?

Module guidance favors focused modules with a clear responsibility, composed together in the root module, over a single module that tries to serve every case through flags. Splitting the networking module into, for example, core network, routing and endpoint modules gives each a small, stable interface, lets teams version and upgrade the pieces independently, and means a change to one concern no longer forces every consumer through a risky upgrade. Root modules wire the pieces together by passing one module's outputs into another's inputs. Adding further feature flags makes the existing problem worse: each flag multiplies the combinations that must be tested and widens the surface for breaking changes. Replacing typed inputs with a single loosely typed map removes the documentation, type checking and validation that make up the module's contract, so callers learn about mistakes only at plan or apply time. Forking a copy per team recreates the drift that modules exist to prevent and ends shared fixes. Exam caveat: decomposing a published module changes resource addresses for callers, so ship moved blocks and a major version with upgrade notes. Operational check: list each input variable and the resources it affects; inputs that only toggle unrelated resource groups mark the boundaries for the split.