This is a very interesting discussion to me. I'm still on the fence about the idea of putting links in API formats. For HTML that works of course, because we understand contexts and meanings. Usually. But libraries have a harder time doing this and semantics only goes so far.
Another short term problem I would see is adoption of this on the API provider side. That's of course something a well coordinated initiative would take care of.
I'm looking forward to seeing where this goes and learning more about it.
We're not so much trying to make this an abstraction layer as we want to make this a library of API definitions that are clear, machine- as well as human-readable (to a point) format, that can be made usable by a connection factory instead of making it necessary to generate and maintain libraries.
This is a good point that we discussed, too. While Hal, like HATEOAS is very interesting and definitely a simplification that's necessary to make our lives better, we're aiming at something different: we're trying to describe existing (ReST) APIs in a way that a single library using a Factory Pattern can turn into connections that you as a developer can use to work with that API.
We settled for the swagger format, because its very flexible, human-readable and honestly can be turned into very nice looking documentation pages.
Another short term problem I would see is adoption of this on the API provider side. That's of course something a well coordinated initiative would take care of.
I'm looking forward to seeing where this goes and learning more about it.