Multiple calls to MetadataTriggerHandler().run()

[pasres]

Disclaimer: I know the framework works as intended, so this is more of an open question. I'll still put it in the form of an issue.
Please feel free to just dismiss and close it if you feel this is beyond the scope of the framework.
Thanks in advance!

Expected Behavior

• When having two triggers on the same object (please see below on more background for this scenario)
• Both calling MetadataTriggerHandler().run()
• I would want any registered trigger actions to only run once

Actual Behavior

• Trigger actions run twice

Steps to Reproduce the Problem

1. Add 2 triggers on Account, both calling MetadataTriggerHandler().run()
2. Add SObject_Trigger_Setting__mdt for Account
3. Add one Trigger_Action__mdt calling some code
4. Execute UI or other change to run trigger

Specifications

• Version: 0.2.8
• Platform: Production org, managed package installation

Background: We are developing 2GP managed packages. We would like to package the framework (think of it as a commons/utilities package) and have other packages depend on it. This could lead to multiple triggers on the same object calling the framework entry point (MetadataTriggerHandler) thus running triggers multiple times.
We are now wondering how to best prevent this (besides manual code review) - if that's even possible. I understand the framework was probably not created with this kind of use case in mind, but maybe it is something worth considering.

[mitchspano]

You should not have two triggers on the same SObject calling MetadataTriggerHandler().run().
The framework is specifically built to handle the orchestration of all trigger logic from one injection point.
In the case of a package trigger, there should only ever be one trigger on the SObject which would be included int he package itself. Clients can then implement the trigger action interfaces and add new logic via custom metadata and retain the single injection point.

[pasres]

Thanks for getting back with the info. We also came to the conclusion that it would be best to package the triggers toghether with the framework. Additionally we implemented it so that the framework entrypoint is not "Namespaceaccessible", so any potential second trigger from another package can't actually call it.