Hm, not sure why you think it's the opposite. My definition is pretty much the same as the first answer from here:

the API is the description of classes/interfaces/methods/... that you call and use to achieve a goal and
the SPI is the description of classes/interfaces/methods/... that you extend and implement to achieve a goal

That's a definition widely accepted in Java-land. Thus I'd prefer if we sticked to this to avoid confusing people familiar with these definitions.

So you want to change the user / integrator Split if today with a true API / SPI split ?

To me it's not one or the other but both actually. We have APIs/SPIs addressing users (naturally that's mostly APIs as they just want to use our stuff instead of customize it) and APIs/SPIs addressing implementors of dialects (most SPIs naturally fall into this category as the point of providing a dialect is customizing certain aspects such as interacting with the data store).

My main concern is that we apply one strategy of naming and organization consistently, whichever it is. Currently there are many types whose package suggests they are API although they aren't (neither in your nor in my definition). Also there is e.g. o.h.o.cfg.spi.OptionConfigurator which I put there not being aware of your definition of SPI. But in fact its a user-facing contract, so when sticking to your model, it would have to move to o.h.o.cfg.OptionConfigurator I guess.