It seems that the problem described in ZBX-18551 affects trigger creation as well. Consider having the following JSON for LLD:

[
   {
       "{#TYPE}": "A",
       "{#DATA}": 1
   },
   {
       "{#TYPE}": "B",
       "{#DATA}": 1
   },
   {
       "{#TYPE}": "A",
       "{#DATA}": 2
   },
   {
       "{#TYPE}": "B",
       "{#DATA}": 2
   }
]

You can look at this as if having two sets of objects (objects A and objects B), each having two values (1 and 2):

• A.1
• B.1
• A.2
• B.2

There are two item prototypes assigned to this LLD rule:

• trap.a[{#DATA}]
• trap.b[{#DATA}]

At this point, this configuration would cause an error as there will be item duplicates, so overrides are added:

• TypeA

  Filter: {#TYPE} mathes A
  Operations: Item prototype contains trap.b
  Discover: No
  

• TypeB

  Filter: {#TYPE} mathes B
  Operations: Item prototype contains trap.a
  Discover: No
  

All 4 items are discovered without problems after the fix made in ZBX-18551, but problems remain with triggers:

• Single item trigger for type A works fine:

  {test:trap.a[{#DATA}].last()}=0

• Single item trigger for type B works fine too:

  {test:trap.b[{#DATA}].last()}=0

• Trigger with both A and B is not created:

  {test:trap.a[{#DATA}].last()}=0 or {test:trap.b[{#DATA}].last()}=0

It is expected that it is possible to create a trigger from multiple item prototypes:

{test:trap.a[{#DATA}].last()}=0 or {test:trap.b[{#DATA}].last()}=0