It seems to be a polarizing idea. Many people can't stand it, but also I suspect that very few actually worked with something like that.

In any case, I believe that it's better to build a data model/storage without that concept (read: don't store the data in the same branch as the code) to have the freedom to built it with less constraint and make it right. Once that work you can add this "branch sensitivity" concept on top and again make it exactly how you want it.

An example of problem you get when storing the bug data in normal code branch: cool, you got the bugs state deeply stick with the code so you know exactly when a bug is resolved and in which branch. But now you are stuck with git only to deal with merge conflict, which means you might need to have the user fix it when it goes wrong. Will you push that to a non-technical person as well? Also, what happen when you rebase or cherry-pick?

Consider the "no overarching view" part: if you just cloned the repo, you'll see a bunch of open issues and no hint that they're already being worked on, because you have to check out each branch to see if that issue has updates.