You are partially correct with regards to the Grafana datasource having the issue.
Generally the openHistorian Alarms consist of 2 signals or points. (1) the signal you are Alarming on (the same frequency in your case) and (2) a point to store the Alarm (naming based on the PointTag Field).
For retrieving the Alarm there are 2 different ways of doing it. The Manager (in monitoring > view alarm status) pulls the current alarms from memory. This means it does not care about the Tag name because it only needs to know whether the alarm is currently active.
Grafana on the other hand pulls the data from the stored point (or signal). This means if both of your alarms save to the same point Grafana won’t be able to distinguish between the two. Because there is no way for Grafana to know which description to grab it will just pick the first one (the high one in your case),
If you change the Point Tag in the Alarm setup to be unique this is resolved because then the alarms are saved as 2 separate signals meaning Grafana would be able to distinguish between the two. Note that this does not fix any instance of the Alarm going off in the past since these are already saved to the original point (or signal).
I suspect you found a bug in the Manager where we did not account for the possibility of 2 Alarms with the same severity and the same signal being set up. You should be able to get around this by manually renaming the PointTag to something unique (e.g. add _LOWER and _UPPER at the end)