Documentation about user macro's tells:

Note that the numbered macro syntax of {MACRO<1-9>} is used to reference hosts in the order in which they appear in a trigger expression. Thus, macros like {HOST.IP1}, {HOST.IP2}, {HOST.IP3} will resolve to the IP of the first, second and third host in the trigger expression, providing the expression contains those hosts.

However, then documentation tells that these macros can be used, in particular, in "Item key parameters". The note "2" warns that these macros are "supported in item key parameters", but "will only work in item types that have interfaces" only. There is no other warning.

In reality a processing of such indexed macros ({HOST.IP1}, {HOST.IP2}, etc) in the item key parameters just ignores these indexes, transforming these macros to {HOST.IP}

It often causes to false impression that the indexed macros like {HOST.IP1}, {HOST.IP2}, etc. and {HOST.CONN1}, {HOST.CONN2}, etc. relates to the first, second, etc. interfaces of the given host when these macros are used in the item key parameters. Some typical examples of such misunderstanding could be found in russian-speaking forum: example 1, example 2.

My proposal is the following: the note "2" should be expanded by an additional sentence, something like the following:

When {HOST.*} macros are used in the item parameters, macro indexes are not supported and just ignored. For example, {HOST.IP1}, {HOST.IP2}, etc. and {HOST.CONN1}, {HOST.CONN2}, etc. macros will be processed just as and {HOST.IP} and {HOST.CONN} (i.e. relates to the default interface for the host).