How do I write a maintainable Terraform template

for my company I have been tasked with creating a standard configuration and template for an (EKS) Kubernetes cluster in Terraform that can be deployed using GitLab CI/CD. The deployment and configuration has been done for a while, but I have been struggling with the template side of things.

Here's my task: create a template project/repo with configuration that someone else can copy and edit.

However, I need to then be able to update my configuration to match versions or new features in the future and they then need to clone/copy/merge my template back into their configuration without overwriting their specific configuration.

I have asked one of the more senior developers for advice and he recommended to me to create a sort of configuration file (like a .tfvars file for Terraform) where the specific configuration can go into, and then I can abstract my template and update it without affecting the configuration in the future. This would work on the surface and for now, but as features get added and more specific requests for me come in, this would only become more and more unmaintainable in the future it seems.
Another option would be to use Terraform modules, but this suffers from the same possible side effect of growing into an unmaintainable mess later on.

So, I am at a loss here. This doesn't seem very maintainable for me or them in the future. Most importantly, when a major version update happens for my template, their configuration will surely break without a way for me to fix that without a lot of manual work. I want to do a little more work now, so it can be maintainable in the future with as little work as possible, but I can't seem to find a good solution.

So my question to you all becomes: How do I properly create a maintainable Terraform Kubernetes cluster template that I can update with as little effort as possible in the future?

Terraform modules are the intended mechanism for encapsulating a set of declarations into a reusable form.

You mentioned that your primary concern is that features added later may cause the module to grow into an "unmaintainable mess". That is a typical design problem that maintainers of any reusable code must handle: for each new feature someone requests, you'll need to either find a way to integrate it into the existing design or declare that feature to be out of scope and provide a separate solution to that problem, such as another module intended to be used alongside the first one.

There can be no universal answer to the problem of ongoing maintenence of shared code, whether it be in Terraform or otherwise, but the Terraform documentation section Module Composition describes some patterns for breaking problems down into smaller parts that can be combined together in different ways.

That is a common way that module authors avoid the problem you are worried about of a single module's growing to include far more than it was originally designed to include: instead, you can offer your users multiple modules which they can combine together in different ways to handle different situations, so that users who don't need some particular feature can skip including its corresponding module while still using the other modules.