Thinking aloud here...

I like your idea of capturing some requirement(s) that motivated the extra complexity, and retaining those requirements in a place they'll be seen and consulted when any new release planning and architecture happens.

This seems related something I do when scoping an MVP or release: work through the requirements breakdown, and mark the things we considered but decided not to do in that release (the "NON-Reqs"). Keeping them in the document gets everyone who looks at it up to speed, so we don't keep rehashing, and also makes it very clear to people that this thing someone told them the system would do is definitely not happening (a very-very-very common miscommunication in some companies).

But if a NON-Reqs suggests some future growth affordances that I think are important to try to include in the new architecture work now, to avoid/reduce very expensive refactoring/rewrites/rearchitecture in the near future, maybe some of those NON-Reqs should be moved to bulletpoints in a requirements section like "Architecture Growth Affordances", and become medium-priority requirements not to preclude in the architecture. Where it can be triaged, prioritized, and traced like any other requirements.

I like that idea a bit, but a few problems:

* Someone might get confused that you're promising to deliver that in a future release.

* Someone might blame if, when the future release planning comes, you say that feature will take a lot of work, but they thought you already did most of the work for it in the previous release.

* You'll need everyone involved to find the right balance of how much to think about about this release, and how much to keep in mind ability to do future releases. By default, people will have a lot of trouble with both kinds of thinking.

* A lot of these architectural decisions with growth in mind will happen after the requirements are locked in, and making frequent changes to that set of requirements is a very confusing precedent to set. (For example, most people won't take the commitment to the requirements seriously, if they think things can just be tossed into it later as needed, or if they think you're just doing incompetent theatre. You want them to get the idea "anything that isn't committed to in the requirements, isn't happening in the release; so everyone think and agree hard together now, so that we'll all be working effectively and efficiently towards the same viable release". Only after everyone gets that, do you introduce the flexibility.)

Maybe those requirements should go to a place for "anticipated future requirements" (but that isn't only a backlog of "candidate requirements"), in that it can be referenced for traceability when you make an architectural decision with future options in mind?

Or, the fallback (which I've used countless times) is to document with the architecture (embedded in the code, or in other canonical arch docs) the rationale for the decisions. Then, when someone goes to change the architecture, that information is hopefully somewhere they'll see. (This assumes that the person changing the architecture is a smart professional.)