Triggers should work in isolation, with a final conflict detection step

Dear pgsql hackers,

I am Gianluca Calcagni, a Salesforce Certified Technical Architect. In the course of my career, I accumulated extensive experience working with triggers, both as an architect and as a developer.

When I work with multiple developer teams, they often need to create triggers on the same object: when that happens, I usually recommend them to maintain a single common trigger rather than multiple ones - the rationale being that, by sharing the code, they can minimise most "negative" interactions, such as recursion, trigger cascades, for-loops, multiple DMLs on the same record, and so on. In the Salesforce ecosystem, such approach is considered a best practice (for good reason).

The real drawback is that such approach is forgoing the natural principle of "separation of concerns"! I have been looking into using trigger frameworks to solve this problem, but there is no trigger framework that is able to meet my main expectations: in short, isolation and conflict detection.

This is what I want to see:

1. when an event is firing two or more triggers, then such triggers must be executed within the same transaction, but each trigger must be executed in its own isolated context (in the sense that it cannot see the changes applied by any trigger other than itself)
2. when all the triggers are done, postgres must merge the results together and stage an end-result
3. postgres must raise all possible conflicts (in the sense that, if a specific field on some record has distinct changes applied by different triggers, then the end-result of the transaction is ambiguous hence the entire transaction should fail)
4. If everything goes fine, the end-result of the transaction is finally committed to the database.

You may notice that I took inspiration from GIT for most of the concepts above (e.g. "isolation" actually means "forking").

I realize that this is a huge request, but I believe there is some merit in the idea. I also realize that there are very complicated implementation nuances (e.g. in handling foreign keys and constraints), but I am happy to provide more input about my vision of this feature.

Looking forward to your feedback!

Wish you all a great day,
Gianluca