The XP-Pen hardware reports HID "Eraser" usage (some digitizers with accompanying HID "Invert" usage, others without) for the top button. Linux' generic driver does here nothing more than forwarding the corresponding events from hardware to the userspace.
The missing Invert usage caused Linux to report Eraser as regular tip touch to the userspace, which was not intended but caused by an oversight in the kernel code. This, together with a bunch of hacks (Digimend and X11 tweaks), allowed OP to map that button to a right click.
Now, with the kernel logic fixed, these hacks do not work anymore. This is a case of xkcd://1172. The userspace solution is to remap BTN_TOOL_RUBBER to a right click for the weird stylus instead.
Yes, barrel switches should ideally be reported as "Barrel Switch" and "Secondary Barrel Switch". I have a Huion tablet[-1] that reports the second barrel switch as Eraser. The secondary barrel switch was not in HID originally[0], and I guess some devices were designed to follow an earlier spec -- that, or avoiding Wacom patents.
[-1] I don't remember if it's also a uclogic controller?
- graphics tablet digitisers generally are not and don't include touch digitisers
- tablets are not touch screens
- a stylus (tip) isn't a button
- a stylus can have buttons
By convention, stylus tip interactions are "tools", which seems to be what Linux' BTN_TOOL_* codes are meant to mean. A button on a stylus should never be (directly) translated to a tool -- like how the ~5th button on a mouse is `BTN_EXTRA`, not `BTN_MOUSE`. In this particular case it looks like the thinking is: the device has 2 event codes (which we know as the stylus tip and the barrel button) and it's a stylus^wdigitiser, so map device[0] to `BTN_DIGI` and device[1] to `BTN_DIGI + 1`.