Steps to reproduce:

This is related to a very common situation, when dealing with low level discovery of Cisco and other vendor MIB OIDs.

1. Suppose you want to discover Fans for Cisco Nexus 5000.
2. I set up discovery rule as follows:
3. discovery{#FAN_STATUS},1.3.6.1.4.1.9.9.117.1.4.1.1.1,{#ENTITY},1.3.6.1.2.1.47.1.1.1.1.7
4. {#FAN_STATUS} 1.3.6.1.4.1.9.9.117.1.4.1.1.1 (cefcFanTrayOperStatus) - this is indexed by "entPhysicalIndex", means that output is like this:

.1.3.6.1.4.1.9.9.117.1.4.1.1.1.534 = INTEGER: 2
.1.3.6.1.4.1.9.9.117.1.4.1.1.1.535 = INTEGER: 2
.1.3.6.1.4.1.9.9.117.1.4.1.1.1.536 = INTEGER: 2
.1.3.6.1.4.1.9.9.117.1.4.1.1.1.537 = INTEGER: 2
.1.3.6.1.4.1.9.9.117.1.4.1.1.1.538 = INTEGER: 2
.1.3.6.1.4.1.9.9.117.1.4.1.1.1.539 = INTEGER: 2
.1.3.6.1.4.1.9.9.117.1.4.1.1.1.100000534 = INTEGER: 2
.1.3.6.1.4.1.9.9.117.1.4.1.1.1.100000535 = INTEGER: 2
.1.3.6.1.4.1.9.9.117.1.4.1.1.1.100000536 = INTEGER: 2
.1.3.6.1.4.1.9.9.117.1.4.1.1.1.110000534 = INTEGER: 2

, where the last number is entPhysicalIndex, ID of physical entity.

1. Now where is the problem?
2. We want to have item prototypes like this

Fan{#ENTITY} Status

Fan{#ENTITY} Speed (%)

Fan{#ENTITY} Speed (RPM)

, which makes sense, so that it is clear, where this fan is located, at which entity.

Not just unclear variants of Fan{#SNMPINDEX} which would produce unclear item names like: Fan[1000121] Status.

1. The problem is that Zabbix for whatever reason decides that it should index ALL MACROs by the most largely indexed one MACRO, which is not how this should work.

Result:

In result I get all items like should be and working fine:

 BUT, there is this thing for discovery rule, which should not even occur in this case:

This is shown because Zabbix tries to index ALL macros by a macro which has a larger index.

Expected:
The indexing should be made by the first element in discovery rule.