Thanks, everyone, for the responses.
I don't understand why the library/extension duality is a problem.
I don't think it is a _problem_ it just feels strange to me. Maybe I'm misunderstanding, is it possible to use TH without using the library components?
Shouldn't specialized features be defined in terms of general features?
Absolutely, but usually don't you use the specialized features over general ones where you can? For example, I don't often (if ever) use the general feature of the goto statement in C. Instead I use conditionals, loops, and functions. I don't often write explicitly recursive functions in Haskell, rather I use map, filter, fold, etc. whenever the structure of the recursion allows.
How does this differ from the current QuasiQuotes extension? From what I can tell, all you need to achieve this with TH is to automatically derive a Language.Haskell.TH.Lift instance for JsonObject, i.e. a function lift :: JsonObject -> Q Exp such that the expression will evaluate to the original JsonObject. A QuasiQuoter like the one you describe can then be created by QuasiQuoter { parseExp = lift . json }.
Right, it's not a lot of extra work. But it's enough that in most cases, I stick with constructing records or using other built-in syntax.
Should both approaches be supported directly, or should we sacrifice the generality of the current quoters for the simplicity of the ones you suggest?
No, I don't think TH should be sacrificed. I just think more specific (and more simple) features might be nice in place of some of TH's specific uses.