The choice to not use git merge handling was there from the beginning, the proper CRDT came a bit later when I understood more the problem and it's possible solutions. From a UX perspective, manually fixing merge conflict is the right thing for code, but it's a different story for social interactions: when the output you operate on is code, you want to precisely control that output. When the output is people understanding each other, you want to capture the intent. It's ok to, in rare case, be a little bit off in edge cases of the conflict resolution. What's not ok is forcing on the user to understand and deal with the problem.

Note that this very question is why some previous attempt at distributed bug tracker failed.

As for the postmodernism of git, I don't know ;-). I'm simply building on top of the lower level git database and leveraging the tools I have (like push/pull). Each bug is essentially its own namespace of operations that get moved around between repos. As with any CRDT, the state of that document get built from what is known at the time.