I'll concede that packet size might need to get bigger if you have the server send the damage type along with the damage and weren't already sending that. That would probably even be the better way to do it since it's fully reliable.

As far as I can tell, the plugin that does this works by reading the static game files that are downloaded from the launcher. It gets that data via the more generic plugin framework, which uses a library for reading game files. Within this static data is a table of actions and their damage type, suitable for implementing this feature completely client-side with no server changes whatsoever.

In terms of feasibility to implement this feature the same way the plugin does, simply keeping the relevant parts of this table around in memory 24/7 is a very small increase to memory usage while the game is running, but it's not 100% reliable unless the game data itself is changed to contain 100% of the information. The plugin claims to have some cases where it cannot detect a mismatch between the type while the action is being cast vs. when the damage comes out. The static game data could potentially be changed to cover these cases.

What I really have a problem with is Yoshi P's response.

If you mean to say that you would need to change the flying text code when you change the damage type of something, this is not what anyone is asking for. You do not touch the flying text after you touch it once to add support for displaying damage in the appropriate colour. Once that support is there, all you change is the action itself, whose data will propagate through to the UI when it's time to show the flying text. Changing anything about the flying text code when you change the damage type of something would be awful software engineering.

Now you said QA specifically. If you instead mean that you require extra QA time to verify the change of damage type, that's another red flag. QA should absolutely already be checking the damage type. QA testing that the flying text displays the correct colour is a one-time thing that happens when you change the flying text, or at least until you're confident it works.

Let's examine the cases for testing that the damage type changed at the last minute:

If you have an internal debugging tool to display the damage type to the QA testers so they can verify it, then you're a hair away from implementing this feature already. It might be a quick hack right now, but can most likely be polished up into an actual feature.

If you don't have such a tool, then once you're confident in the flying text change, you've made QA's job much easier for all future damage type checking by adding this feature. Rather than whatever tedious method they were using to verify the damage type of each action, they can rely on the flying text. Perhaps you'd use a debug version that supports every damage type instead of only physical vs. magical.