Allow configparser to process duplicate options, just concatenating it's values, so using file

[sect1]
opt1=asd;
opt2=qwe
opt1=fgs

we will have config['sect1']['opt1'] == 'asd;fgs'

Thanks for the report.  Could you tell us more about the use cases?  Are you aware of some config files using this form?

There is some [leagcy] proprietary soft-switches, which uses this config format.
Personally I use [hacked] configparser to process Mera systems MVTS/SIP-HIT configs in this format, for example.

This would break existing config files, including some of my own. 

It would also require that you have some end delimiter on every item in order to handle the event that someone duplicates options, otherwise the following would likely behave badly in your application

[sect]
opt=first
opt=second

This would give you "firstsecond" that you'd somehow need to parse. Sometimes if I'm testing out options, like I want to check how "second" works, I'll quickly just do it as above. With a change like this, I couldn't do that, I'd be forced to comment out the first line, or add a delimiter and split on it.

It may be impelmented as configparser.ConfigParser(strict=yes|no|multiline), so no existing configs will be broken.

This specific config format you're discussing strikes me as error prone and barely useful. With the use case you've given I cannot justify introducing support for it in the standard library. Remember that each switch, variant, however obscure and rarely used, increases source code complexity and introduces a maintenance burden.

As you've seen with the freshly introduced `strict` option, we're generally heading the other direction: to let application users know early they potentially made a misconfiguration that could confuse them later on.

So, thanks for your feedback but unfortunately I will have to say no to that proposal.