Here's another meta-format worthy of consideration.
A *package* is a collection of resources with relationships
between them and relationships linking them to other things
like authors (think Dublin Core).

I really like this approach of thinking about packages. Apart from the obvious benefits of some concrete format like RDF (e.g. mixing with OpenDocument files), this way of thinking could open the door to some interesting ways to see existing problems. As an extension, those perspectives might lead to fruitful experiments. (After all Haskell was originally created as an language to be experimented with - so why not expand that to packaging?) Just two ideas off the top of my head:

• One could proclaim that part of the orphan-instances-/forced-imports-ugliness stems from the fact that instances formulate a kind of relationship between declarations and are thus fundamentally different from these other declarations. So one might want to experiment with separating both by adapting the package format and see what benefits or drawbacks that brings.

• Similarly one could proclaim that one of the things that makes the dependency purgatory difficult to navigate is that version numbers alone do not encode enough information - but a finer grained analysis might. E.g. imagine you could say "I have tested with package X in version 0.3.4. But feel free to substitute any other version as long as functions A and B haven't changed, because these are the only ones I use." There are obvious problems with such an approach, but I propose that we can only find a way forward by experimenting - including experimenting with such details of the relationship.
  

Note that I'm not saying that experiments like these are impossible with a format like cabal or yaml. All I'm saying is that thinking of packages as resources in relationships makes it easier to think in these ways. An appropriate representation could be both a tool to shape our thoughts and a tool that, being specialized for the representation of relationships, makes it easier to incorporate experimental features without breaking the ecosystem. It will probably be unavoidable to "inject" some code into the solver for a specific package for such experiments, but I hope that understanding the details will make it possible to see ways how to do that in safe and portable ways.

MarLinn