The February 2013 draft, section 6.4.2, says "If ianaTimeZone is a Link name, then let ianaTimeZone be the corresponding Zone name as specified in the “backward” file of the IANA Time Zone Database."
Not all Link names in the IANA Time Zone Database are defined in the "backward" file - there are more in several other files. The intent here is to treat all Zone names as canonical names and all Link names as aliases, irrespective of where they are defined.
There are two possible forms of canonicalization, and the ECMA group should be careful which one to choose.
The IANA database contains a number of source data files, such as europe, northamerica and backward. The backward file consists of Link entries that map an old ID to a new ID. The file is distinct in that it can be used to identify IDs that have replacements. This usage is not entirely formalized within the TZDB community, but it pretty effective in practice. For example, Asia/Calcutta is in backward pointing at the modern preferred spelling of Asia/Kolkata. Canonicalizing these "backward" IDs to more modern alternatives is non-controversial, as they can be simply treated as deprecated IDs.
The second type of Link occurs in the "main" files (not "backward"). Those links exist to indicate that two locations have a shared history of time (since 1970 and possibly before then). These links can cross politically sensitive boundaries. For example, the time-zone IDs for all the Yugoslavian countries all share the same history since 1970. As such, they consist of Link entries to a single Europe/Belgrade definition that defines the underlying data. Were ECMA to canonicalize IDs here there could well be political complaints. ie. converting Europe/Zagreb to Europe/Belgrade could prove to be highly unpopular and contentious, even though both have the same time-zone history.
Thus, two forms of canonicalization. The 'safe' one, simply canonicalizing old IDs. And the 'contentious' one, canonicalizing all Link entries even when across recently wartorn boundaries.