Hi @Andrew_Davis1,
I think this is and will always be an open discussion.
If I can put my two cents on it, I’d just say that data modelling should take into consideration the overall data lifecycle.
I use to simplify it by dividing into three main data perspectives:
- Semantic: “what is what”
- Interactive: “who, when and how is “actively” using it”
- Informative: “what (aggregated) information I need to extract” (what @Philip_Johnson1 also pointed out)
Many times (too often) we tend to rely on the first one only.
Very rarely though the three ones can converge to the perfect solution.
The very good thing in Coda is that you can design the three of them within the same application.
In your example I’d assume the Epic and Story might be fed and maintained by similar people and they need specific interfaces and solutions for that purpose only.
Similarly, Task and Bug can rely on the same premises and need to keep track of a good deal of similar columns.
So, maybe it could even be an hybrid solution with a Narrative or Vision table with a self referential hierarchy (Epic and Story) and Activity (where Task and Bug are just different types and there are no hierarchies).
Again, it’s just a suggestion: don’t take it as a solution unless it fits the full usage needs.
Trying to describe the whole process would help to understand where to draw boundaries among the aforementioned perspectives and what to prioritise.
As per the "single Issue" concept, I’m not against it but only if we had a polymorphic data structure.
(have a look at this post: Extension Tables)
Meaning we could group together only the common features.
But we don’t have it (and it’s not necessarily a bad thing) and maybe having an “holistic” table (all the columns for all the types) could even work.
I hope I just didn’t create more confusion than clarity 
Cheers!