This page will track the required changes to cleanup the current triggers implementation.
One of the problems that has been plaguing Debian since triggers started to get used has been the dreaded trigger cycles. The main reason for this is that the initial implementation pretty much defaulted all over the place to use awaiting triggers, which are the ones that can get us into those cycles.
Later on we added support for -noawait trigger directives and even later, support for explicit -await directives and an --await option to dpkg-trigger.
But maintainers are still defaulting to the implicit trigger directives adding lots of unsuspecting cycles.
Also reasoning and analyzing trigger cycles is not easy, and it seems the piuparts and dpkg maintainers are the current bottleneck. 
The plan to improve the current situation would be to:
lintian should warn about implicit trigger directives. - dpkg should warn in 1.19.x when finding implicit trigger directives, and state that the meaning will be switched around during the 1.20.x cycle.
- dpkg should switch the trigger directive semantics during the 1.20.x cycle.
- dpkg should emit more information when hitting a cycle so that it can be easily analyzed after the fact w/o needing to reproduce it, which is time consuming. Something equivalent to the output of dpkg --audit might do.