Let me explain the logic behind what you've observed with the ToolsAPI and you can then determine how that applies to your situation. Your reasoning is very close.
For interfaces that are meant to be consumed by plugins and IDE extensions, you are correct about the manner in which the interfaces are versioned and named. The idea is that existing code will reference a particular interface name and because all the existing methods also exist on that interface. Since the older code simply cannot reference any new methods, it's safe to include them in the new interface.
However if you look closely, for interfaces that are meant to be implemented by the plugin or IDE extension, you will see that the reverse is true. The new interfaces get new names and all the older existing interfaces remain unchanged. This is because, as the implementer of the interface you must implement all the methods of an interface. Existing code, by definition, will not have implemented the new methods. When the IDE needs to call a user's implemented method, it will always make that call by querying for the version of the interface on which that method was introduced, which may not be the most recent version of the interface. For this reason one should list all ancestral interfaces as being implemented on the implementing class.
In summary, the rule here for the IDE's ToolsAPI are that for interfaces that plugins use, the newest version of the interface always gets the unversioned name. For interfaces that the plugin implements, new interfaces always get a new name.