I wasn't sure that it need be an array either - I first made the 'fixing' pull request to the hal browser first and got this response:
https://github.com/mikekelly/hal-browser/pull/24#issuecomment-24995680

Yes, the spec is clearly ambiguous, although Mike's comments clarify nicely. It certainly doesn't feel right - although it makes parsing in JS easier there's a nice slippery slope logic that could be used with regard to any HAL parsing (i.e. for simplicity have everything expanded). Obviously that's hard to support unless you're using JS and aren't using a HAL api.

I'm not sure about your solution. By giving the user the ability to decide whether to use an expanded rel or a collapsed rel, you allow the user to apply meaning to their choice whether to expand or not (for example, a collapsed link might be a link where there will only ever be one, an expanded might be a link where there could be multiple at some point in the future). This is bad because it fundamentally makes hal+json more powerful than hal+xml - two representations with different meanings in hal+json would have the same representation in hal+xml.
Practically, it makes no difference for anyone using any kind of hal library - it only makes a difference for those who code in barebones javascript (as far as I can work out) - and if they weren't coding for the option that it might be a single link (or in the other direction, an array) they'd not have implemented HAL correctly. If it's emphasised from the start that if you're handling hal documents, you must prepare for the possibility that there are multiple links with the same rel (for example, in halbuilder with getLinksByRel returning a List<String>). There are arguments for allowing the choice for the purposes of allowing people who've implemented deficiently to not have their application broken if a document changes, but really this should not be necessary - it's such a core part of the hal spec that they should have done it in the first place or just used a library.

The only reason I stopped the discussion about the curies rel with Mike is that curies are handled differently in XML with namespaces, so there's a solid argument for treating them specially in JSON as well.