When the same parameter is assigned value multiple times within a single template call, currently a red warning is displayed above the edit window upon preview:

Warning: Example is calling Module:MeetupDates with more than one value for the "20170321" parameter. Only the last value provided will be used.

The last sentence of this message clearly states what is the rule in such a case – that the last assignment takes priority.

Now I have created a module that calculates the dates of several close meetups, but allows the user to mute some of the calculated dates (by reseting the corresponding parameter to 0) or add their own dates (and setting the corresponding parameters to 1):

{{#invoke:MeetupDates
| {{some magic to generate the most recent past date}} = 1
| {{some magic to generate the closest future date}} = 1
| {{some magic to generate the second closest future date}} = 1
| 20170321 = 0  <!-- this mutes a date if such a one was generated by some of the magics above - we use it to skip a date in the calculated sequence -->
| 20170322 = 1  <!-- this inserts an extra date into the sequence, possibly as a replacement for a muted one -->
}}

The point is that even non-skilled users can easily make minor corrections to this otherwise regular and automatically calculated sequence of dates. The "magics" remain untouched, because the parameter name they generate changes in time, and in order to mute a certain date (if it is present in the current sequence at all), the corresponding parameter is assigned (possibly reassigned) the value 0. In the end, only parameters of value 1 are taken into account by the actual module. Therefore, this code relies on the well-documented behavior that only the last assigned value to a parameter is valid.

I had such a template in production, but the community was repeatedly complaining about the red error linked to the "duplicate parameter assignment" they saw whenever editing the page that my code was placed in. However, in my point of view, this is not a bug, but a feature. I suggest that the warning message should be made less prominent, or that code author should be given a possibility to overcome it in some way. Relying on a documented behavior should not be punished by having to see a big red "probable error" message all the time.