Hi Lidia,
It is an interesting question. Generally no guarantee is made about the order extensions are loaded - and indeed changing the order something is installed, or the name of the bundle that includes it can affect what order extensions are loaded, and therefore the order Platform.getExtensionRegistry().getConfigurationElementsFor returns objects in.
The practical solution may be to sort the templates at the last step, which would be in org.eclipse.cdt.internal.corext.codemanipulation.StubUtility.getFileTemplatesForContentTypes(String[], IProject) - a consistent sorting by using IDs (TemplatePersistenceData.getId()) may help - you can make your new contribution sort top of the list consistently. The ID may not be unique (and may be null) so a secondary sort key by name is a good idea. This would have the nice effect of moving user provided templates to the top of the list (if null IDs are placed there).
The alternative would be to fix the extension point itself to add a priority/ranking. Some extension points have ranking in their definition so that an order can be made later. This SO answer has a simple example[1] - and content types are an example of an actual extension point with a priority [2]. Therefore, it is possible that the best solution is to add a priority/ranking field to the org.eclipse.ui.editors.templates extension point. This would allow a single vendor to have their item higher than built-in versions. However, getting this done in practice may be a lot of work, and I am not actually 100% sure that having templates have a priority makes the most sense. There is probably another metric that should be used to sort the templates in a consistent way (like the ID or name). Note, even if TemplateStoreCore.getTemplateData returns a sorted list, the code in StubUtility needs to be updated based on the way its nested loops iterate the template data list repeatedly.
I hope one of the options gives you the info needed to create a patch for CDT. I look forward to reviewing it when you do.
Jonah
