Hi,
yeah, I use `OverloadedStrings` all the time too, but didn't include it for the reason Joachim mentioned. For me one common pattern where ambiguity occurs is indeed with `aeson`, for example if you are encoding tagged sums you may write:
```
object [ "tag" .= ("inLeft" :: Text) ]
```
The type signature is required so that the `.=` operator knows how to make the JSON value. I don't think that's a big deal, and it's easy to work around (I typically make a helper function for making that field). I'd be OK with it being always on, but I didn't add it as it does require you to change your code sometimes.
As for `RecordWildcards`, I do like the extension as it can make code significantly more readable in some situations (single record manipulation, or constructing large records, especially when effects are involved). I know some folks don't like it, but I hope we can get the extension included in the list, as it is not something that can be used "by accident" and also, using it does not affect a function's interface in any way.
I feel `LambdaCase` is another extension in the same group---in this case I don't really like the extension, but I know other folks like it, so I think it'd be reasonable to add (although I did see we have a proposal for an incompatible alternative, so we'll have to see what to do about that)
-Iavor