This will affect ProveIt when implemented. ProveIt relies on TemplateData to perform its work, much in the same way the VisualEditor does.

@Aklapper: This really is pretty urgent now. I won't raise the priority again, but every day that this is not corrected and ProveIt is live, there is a good chance that Wikipedia is loosing data.
@Sophivorus: Please address this urgently: either 1) Disable ProveIt again until this is fixed, or 2) add code as a popup when an editor tries to use ProveIt warning of this behavior or 3) fix it as discussed.
It well and truly pains me to say this because I am a huge fan of the gadget, but right now ProveIt is working contrary to its intention with this bug.

The more I look into this, the worse it gets! In the English Wikipedia, the cite templates supports many varieties of author<n> where <n> is an arbitrary number. Adding all these into TemplateData is a large undertaking, and in some cases will be so absurd that it may make the TemplateData so unwieldy as to become useless.
For example, in cite journal, there are articles with over 750 names! This would mean adding 1500 entries to TemplateData. (lastn, firstn times 750)
PLEASE fix this behavior of ProveIt so that data is not lost. Just pass them though for the moment if you have to. If you can display them in red as unknown, that would be even better. But please stop the potential data loss.
BTW, I have been working on cite book TemplateData. it is slow, but coming together.

@Iniquity I agree that TemplateData should be updated to match the actual behavior of the template itself. I would still argue that this must be fixed, and that is should be fixed before making this version of ProveIt live.

As a end user editor, I want unsupported parameters retained, along with their corresponding value, so that I do not lose data.

Well, according to this link for regex recursion referred to in the stackoverflow discussion, regex might still be the answer, if the Wiki software implements it.