| 20 Mar 2026 |
 Sergei Zimmerman (xokdvium) | I recall there seemed to be some AWS endpoint that legitimately used duplicate keys too | 10:34:41 |
| Sergei Zimmerman (xokdvium) | Though I’m not sure I can find the reference now | 10:35:15 |
 piegames | let me rephrase the question, are there any reasonable use cases for duplicate keys where parsing both and then using only one of the values is the correct behavior? | 10:36:19 |
 emily | it's sorta like asking if there's any use case for parsing web pages with invalid HTML the same way everyone else parses them | 10:37:24 |
| emily | the use case is you can browse the web like everyone else | 10:37:36 |
| emily | the documents are dodgy from an interoperability/sanity standpoint, but when they exist in the wild and everyone treats them the same way in practice… | 10:37:55 |
 Qyriad | Unfortunately retaining only one of the values is arguably a more compatible behavior because the alternative is e.g. parsing them into a list, which is an entirely different type | 10:38:10 |
| emily | it's plausible you'd want the ability to get all the values of duplicated keys for some documents, but that's more in the territory of extending the language with more optional functionality than a reason to break stuff with the existing API | 10:38:32 |
| emily | yeah, an alternate API would probably have to wrap every value in a list, or realistically you'd potentially care about the order too in that case, so just to a parse tree with lists of key, value pairs | 10:38:58 |
| emily | but I doubt there's much demand for this | 10:39:04 |
