How about cabal-install using the YAML format as hpack has proven that it works very well for expressing the existing .cabal files? YAML is simple, flexible and open, used across many tools so the knowledge of format is more widely sharable which has its advantages. Are there reasons to keep using the cabal format other than the legacy reasons and the pain of asking everyone to move to another format?
I understand YAML is a very popular format, but it is not all roses. It's an extremely complicated format (http://yaml.org/spec/1.2/spec.html). Cabal's lexical format is very simple, because it doesn't really need to support much (the rest is deferred to sub-parsers on fields.) In some since, YAML is overkill for Stack, which actually doesn't use very many of its features (https://docs.haskellstack.org/en/stable/yaml_configuration/) If I were designing a package ecosystem from scratch, I'm not sure what format I would pick. Take Rust Cargo; they didn't use YAML, they used TOML (https://github.com/toml-lang/toml) in no small part due to the fact that YAML is complicated. I'd want the output to be associated with locations so I could give error messages that refer to the input file; no one does that today...
Inputs from original stack authors might also be useful on why they chose YAML over .cabal. I guess it might be similar to the reasons why someone wrote hpack to generate .cabal from YAML. Also they were starting fresh and so did not have to manage a disruptive change. But I fear if they will be willing to go for a closed format against an open format now even if some of the problems of the format are addressed. Maintaining a closed format perennially is also an issue unless it is very well thought out and does not require any changes.
I suspect the reason is much more banal: Cabal's parser implementation is pretty byzantine and difficult to use. So rather than fight something like that, just use something will a nicer API. Edward