When API keys were introduced they were primarily driven by Hadoop ES use case. Naming an API key was a nice to have feature but got preemptively built with constraints like it being unique across active API keys.

The current design does not guarantee this behavior as when we create an API key we do not refresh index immediately (the default is wait_for) and so it is not available when creating another API key with the same name where the request arrives before the refresh.

Given that we are now using API keys across the board for various use cases like Cloud, Hadoop, Fleet, Alerting, etc. we need to think whether we want to continue with this constraint.

As far as I remember the comment was to have a named API key but whether it should be unique across API keys was something that we decided runtime as I could not find/remember any discussion around it.
Although minor another possible problem to keep into consideration is the indexing/creation speed that gets impacted due to this constraint.

This issue exists to discuss the following:

• Do we think the constraint of unique API key name is of value?
• If not can we remove this constraint? so the name can be considered as a tag.
• If yes do we want to refresh immediately(as default) after indexing new API key document?