inaccurate seconds behind master calculation in chained replication

Hello,

In one of my projects I have a chained replication setup:
master -> (slave|master) -> slave
2nd server acts as a slave for the 1st server and as a master for 2nd server at the same time.

The configuration isn't using GTID.

Lately 1st slave (intermediate master) started delaying behind primary master (caused by problems I am recently working on).
However, its slave is not delaying at all behind it because it replicates only few tables and thus replication happens quite fast.

Last slave in a chain is always 0 seconds behind master, however, sometimes it reports the global delay that happens on an intermediate master (the 1st slave in a chain), like if it's aware of the whole topology and a replication delay on that intermediate master.

What I know about calculation of 'seconds behind master' is that last executed query's timestamp is compared to the very recent query's timestamp received from the master (meaning newest query in relay log).
In 5.5.x (and all previous versions) it works exactly as expected, and the slave was aware only about its delay behind its own master.
However, here sometimes slave shows 0 seconds, and sometimes some global delay behind the very 1st master in a chain.
Could be it's somehow related to all that GTID info in binary logs.

As a result, I am not sure I always know what is the real delay on last slave.
I think it's important to know any slave's personal delay behind its own, directly connected master.
Or have an option to switch that info to use global data in a chain and display delay as a whole in a chain (if that's relevant to someone at all)

Thanks!
Alex