Unfortunately this will not work and that is why it is not present in the core.

The reason is that you can apply a tag to any supported component. So for example when you create a menu item for the "red" tag that include articles and contacts and there is no way for you to order them

Right, not a complete feature, but it will work in a single tag, single component scenario and in my opinion it would be useful anyway (as this way you can use tags as a replacement of the missing multi-category functionality and have a minimal per-component single-tag/category elements ordering).

and how do you explain the limitation to the user - otherwise they will think its a bug. This is a fundamental limitation of a vertical component such as tags

"core.ordering will work just with a single tag in a single component".

I agree with you: tags component should be expanded.
To improve ordering I suggest:

1. create a table #__tags_groups: id, tags_ids_listing (a key from #__tags.id table).
   This will list only the tags groupings created by the user.

2. create a table #__tagged_groups_ordering: id, group-id (from #__tags_groups.id), ordering

3. expand component_tags to allow creation of tags_groups, listing of emelents with that tags and ordering of that elements.

This will be enought to support ordering of any combination of tags, across different components. So we'll have a real and complete core.ordering criteria.

Unfortunately at the moment I am not able to write 3)... but It seems to me that it should be quite standard code for people able to create components (I am not sure it's so easy considering tags hierarchy), so I hope that someone sooner or later will write it!

@mbabker can we have a decision on this PR please.

https://issues.joomla.org/tracker/joomla-cms/17379#event-300520

I think if we're going to add the ordering option we really need to make it work consistently with cross-component data (and as pointed out, that's not easy; I had to do something recently to allow a client to order featured items for 3 different data types and that's a lot of mapping information to store for such an edge case feature).

I don't think we should merge this with the limitation pointed out.

OK - thanks. I am therefore closing this at this time.

@LivioCavallo if you can find a way to make it work cross-component then you can always create a new PR or updaate this one and it can be reopened. Thanks for trying