...

Since no characters are restricted nothing that previously worked should break based on this KIP. Connectors with an empty name were broken before and could not be deleted anyway, so there is no reason to half-support these any further. It is however a change in behavior to reject these. 

There is are however one scenario two scenarios that is are affected by this change:

Changing of connectors with leading or trailing whitespaces

If an external system is used to manage connectors, the change in connector names could potentially cause this system not to find deployed connectors anymore - if their names contain trailing or leading whitespaces!

...

Based on the above points I would consider this a fringe scenario that should not impact a significant number of people (to be honest, I'd be surprised if anyone is impacted at all). Additionally I can't come up with a valid reason to use trailing or leading whitespaces in connector names.

Creating connectors that only differ in the number of trailing or leading whitespaces

As shown in the table above, multiple input names might be matched to the same output name after this change: "   test" and "test   " would be considered the same after stripping whitespaces. The second create request would be rejected as a connector with the name "test" already exists.

While this is strictly speaking a limitation my personal opinion is that using connector names that differ only in the number of whitespaces at the beginning or end is a recipe for disaster and should not be encouraged.

Rejected alternatives

Initially the proposal was to reject a number of characters as illegal in connector names based on a whitelist or blacklist. However following discussions on the mailinglist it was agreed that we can be very generous in allowing characters in connector names as long as all rest requests are properly url-encoded.

...