See:
https://www.zabbix.org/wiki/Docs/specs/ZBX-4333
ZBX-4333
and try to estimate your attempt again.

After reading issue description I'm not sure I can understand correctly template linkage

I can't see any inconsistency with documentation and specification you have provoded, but it still fails.
I will try to add image like in zabbix specs.

Red arrow on the image is the trigger I am trying to add:

this is not possible as "template pci slots" would have trigger t2 that would depend on trigger t1 from "template server alive", but "template pci slots" is not linked to "template server alive", thus you would get a dependency on a non-existent trigger.

seems to work as expected

If we remove template "pci slots" (and link "ethernet controllers" directly to "HostsA"), then I can create dependency from template "ethernet controllers" to template "server alive", but they also are not linked.
It is possible just because thay are templates and if we will try to link template "ethernet controllers" (in simplified scheme without template "pci slots") to host, then we would get error "Trigger in template ethernet controllers has dependency with trigger in template server alive".

To conclude: 1-level templates may have trigger with dependency to any other not linked template, but 2 level templates may not.

Seems to be wrong, isn't it?

no, that seems to be correct. in that case both "template ethernet controllers" and "template server alive" are linked to "template HostsA", and trigger dependency has the trigger to rely on.

think about it this way - if t2 on "template pci slots" ends up depending on t1... there is no t1 on "template pci slots"

think about it this way - if t2 on "template pci slots" ends up depending on t1... there is no t1 on "template pci slots"

Why is it a problem? It's just a template, just as "ethernet controllers".
Template "ethernet controllers" also has trigger t2 depending on t1 and there is no t1 on that template.

It is normal to deny to add hosts to just one template if there are triggers with dependencies to another templates. But templates do not count triggers, so why it should be a problem to have templates with just a half of dependency?

"template ethernet controllers" is the originating template for t1. anything linked to it must have all dependencies, too - that would be t1 in this case.

it does not matter whether it is template or host, it's a configuration data consistency question, nothing to do with trigger evaluation etc

when we link something to a template which has a dep to another template, we resolve that dependency locally, which is not possible in this case

I don's see any reasons to resolve that dependency locally for templates, because we already has inconsistent dependency in template "ethernet controllers" for example.
Don't you think so?

Will this report be considered as problem?

theoretically, we could consider trigger dependencies only when resolving them on hosts and ignore while we are still in templates.
there might be unintended consequences, though - this should be carefully evaluated and tested (both frontend and server changes will be required).
for now it works as designed -> moving this to feature requests

Thank you.

This is REALLY annoying and VERY useful thing - there are many services that depend on each-other and we don't want to create separate templates for all hosts and copy everything we need just to make triggers work.

Possible solution is to:
1. allow creation of triggers, warn if linked element/target doesn't exist
2. disable trigger if linked element doesn't exist
3. warn user upon deletion of linked element and disable trigger
4. warn user upon creation of linked element which will be used by trigger
5. renaming template must not break links - i.e. use template IDs instead of names (back)

I agree. The simplest case: almost all of our hosts have a basic template linked which includes the icmppingsec simple check and an appropriate trigger. We'd like to depend on that trigger for other checks. This cannot be done, neither is there any useable workaround, because:
Item "icmppingsec" already exists on "host", inherited from another template. There are many other cases, this is just a simple example.