Warn on unknown fields, without failing
The presence of unrecognised fields seems like something one might want to be aware of, while still obtaining the parse result. #749 only makes it possible to halt completely.
Admittedly, I'm not sure where this would fit within Aeson's current API. I guess we'd need something like eitherDecodeWarnings :: FromJSON a => ByteString -> Either String ([Warning], a).
I think this would be useful to have, we already have rejectUnknownFields so there might be some way to parse (once with and once without this) but that sounds awkward.
You are correct that the current API does not allow this, but it might be possible to add the option through a non breaking change, such as adding a separate entry point for parsing.
The main thing here, I think, is that we need to show that adding this feature will not affect performance for current users that don't use this feature.
To set some expectations, I don't think this is something that our main contributors are going to invest time in, so it's really up to whoever is interested in this feature to spend the time to get this implemented.
The Parser doesn't allow accumulating warnings (to the first approximation, it's fancy Either Error a).
There are issues like giving rise to https://hackage.haskell.org/package/aeson-commit, which I do think could be in aeson i.e. compare attoparsec which doesn't need try but backtracks arbitrarily and has terrible errors, vs. megaparsec which needs try, doesn't backtrack arbitrarily and have good errors (and warnings if you wish).
I even think that what we get in performance for not allowing arbitrary backtracking can be spend in carrying warnings in the built-in parser state.
Concrete example, if you use <|> with Parser you have to be careful that failing alternatives fail early. (aeson itself doesn't seem to use it, so built-in stuff is fast).
So TL;DR I'm interested in trying using slightly more elaborated Parser on Values, but that will probably be quite invasive change.
We actually created an "add-on" that does exactly this, but has a horrible API and isn't easy to use (or safe) at all, exactly because aeson inherently doesn't keep track of already parsed fields. I might take a stab at figuring out how to adjust aeson to make it possible... some day.