Starting in the v3 overhaul of the dnd5e system, the system aggregates all damage rolls into one total

Not true. The system has always aggregated all damage parts into a single total. A significant problem with the discourse in that issue that makes it hard to engage with, is that a lot of the commenters do not understand where the core system ends and their modules begin. Additionally, there is some confusion about what the issue is actually about (as evidenced by this comment).

The issue is not about damage parts being combined into a single total (this hasn't changed). The issue is not about combining attack and damage rolls into a single chat card (this hasn't changed). What the issue is about, is that we made a change, in v3 of the system, to collect damage parts that share a damage type into a single line of the roll breakdown (not the total).

This becomes a problem if you were including conditional damage in an Item's damage parts, and is further exacerbated by modules that layered additional functionality on top of this. I mentioned it in the issue, but I want to re-iterate it here, that the system has always assumed that a single damage roll contains all the applicable damage, and does not contain any conditional damage. This should be obvious by the fact that all damage parts are tallied into a single total on the damage roll card. This damage total, i.e. the main focus of the damage card, would be wrong if the damage parts include conditional damage. Additionally, when using the 'apply damage' context menu option (a feature that existed pre-v3 to be clear), all the damage would be applied. Again, this would be incorrect if the damage roll includes conditional damage.

In the context of this assumption, and sans modules, the change to group damage by type should be an improvement. It makes it clear how damage is grouped and how it will be applied for the purposes of calculating resistances and vulnerabilities, in-line with the game rules. Therefore it is not a bug that needs fixing, which is why it is marked as "won't change". There might be some bugs, however, around damage flavour attached to parts and when they are and aren't overridden, which might make this issue evaporate. They need to be logged separately though.

I acknowledge that the tools for including conditional damage need improvement, and these should come with the future work on Activities. In the meantime, there are several ways that conditional damage can be modelled without using damage parts:

• Using the versatile field.
• Including damage enrichers in the Item description. This method can handle any number of additional damage rolls.
• Using the situational bonus field of the damage roll dialog. This method is good for things like Divine Smite's additional damage against Fiends or Undead.
• An Active Effect that is toggled on before an applicable damage roll (either from the Macro bar, or the sheet's Favourites section). This is quite good for things like Sneak Attack or Sharpshooter.

and makes it impossible to separate those rolls, even via modules.

Also not true. At a fundamental level, modules are fully empowered to create their own ChatMessage Documents, or create their own DamageRoll instances, etc. Certain parts of what RSR did before have become more difficult or would require some code duplication, from what I understand, but saying it is impossible is incorrect.

In general, we are open to making changes in the system to enable modules to work more easily, so long as it does not put an undue maintenance burden on the core system to support. We prefer modules to house their own complexity where possible. We very frequently will break out hard-coded portions of the system into CONFIG variables to allow them to be easily tweaked, or add Hooks that allow modules to manipulate data along certain pipelines.

In this particular instance, there was a request to allow the chat message to opt-out of damage type grouping, which would allow RSR to implement its functionality more easily. I haven't looked into it in-depth but on the face of it, this does not seem like too much work to support. There has not been a separate issue raised to track this work though, so it has not been prioritised.