Of course once you've got ifthenelse you find yourself wanting explicit desugaring of pattern matching (could view patterns help here?),
Could you be more specific about what you want there, perhaps with a small example? I recognize the other problems from my own forays into EDSLs, but I'm not sure I recognize this one. If you want to reuse the existing 'lhs=rhs' syntax for patterns specific to your EDSL, both QuasiQuotes and ViewPatterns might help, if you want to be able to compose patterns beyond the limitations of that syntax, one of the proposals and libraries for first-class patterns might help, adding functionality at the expense of more complex syntax.
recursion (into an explicit use of fix), etc...
Yes, in principle (you're thinking of sharing, and of lifting pure code?). In practice, too much machinery is attached to the existing 'let' to make that likely. But this reminds me of another closely related issue: GHC offers a lot of help in moving stuff from compiler-baked-in to library-provided, but almost none of the mechanisms works at the level of syntax/AST (where most other languages do their meta-programming/language extension support). RULES and compiler plugins work on core, where it is too late to do EDSL-specific source-level rewrites, TH requires quoted things to parse and type-check in the un-extended language, making it less useful for EDSL-specific language extensions. For instance, think of the arrows syntax: there doesn't seem to be any way that this could have been defined in a library, so it had to be baked into GHC? QuasiQuotes seem to be the only feature that gives source-level control, and they suffer from the lack of easily available parsers (eg, if my EDSL requires an extension of some Haskell construct, I'd like to be able to reuse the Haskell parsers for the baseline). There is a package on hackage targetting that issue (haskell-src-meta), but it relies on a second frontend (haskell-src-ext), and only works with a single GHC version. Claus