Also, I just checked whether it happens across the board with characters that are interpreted as being the same for search purposes, but it looks like this doesn't happen for, say, "event w" with the alias "event v", only for event series with the same hiragana/katakana name.

Katakana and hiragana don't really matter. You could have an event series with all three names set to the same thing and it still fails.

The problem also isn't with the event series, as the same issue can be reproduced when adding a standalone event. If any of the three names or aliases match (normalise to the same string) then the event can't be created.

This is currently working as intended:

The odd things are:

1. Duplicate names are allowed on other entry types (I checked artists, and importantly, event series)
2. When creating an event and a duplicate name is given, a new ID is allocated, but it leads to a 404

@Susko3

1. Tags would be an example of another entry type where every name needs to be unique
2. The ID allocation is just the way SQL DBs handle serial integers. The event is inserted as a transaction, this advances the series, then the transaction gets aborted and the insertion gets rolled back, but not the integer series. This is completely as intended. (So no event is actually ever created with the new ids)

So the core question here is if we should remove the unique name requirements for events and their event series. For that it might be good to know why this rule exists in the first place. @Shiroizu or @andreoda might know more about this.

I ran into this problem (no duplicate event names) again, when adding Digital Stars @ Miku Expo 2024 in Berlin. It was a duplicate of some of the other Digital Stars event, likely due to the same series number (2024). I worked around that by first setting the series number to 20241.