I'll confess I'd selfishly feel sad to see the unity5 tag go, since up until now I've been able to brag that I'm the only user with the unity5 tag badge. ;)
But I agree, there's not much value in distinguishing
unity general versus
unity5 - I can't think of an instance where the tag helped to clearly identify an issue specific to 5.
If we were to do any versioning of the tag at all, the biggest split would be at 4.6, when the new UI and event system features were introduced. I'd give different answers to a user wanting to build GUI in the old system (prefaced with "WHY!?") or NGUI add-ons, versus someone working with the richer native features in later versions.
Unity 5.3 added the SceneManager, changing how we transition between or stream in levels, along with exposing more particle scripting options and sprite asset placeholders. 5.4 added GPU instancing, motion vectors, and texture arrays...
The takeaway is that substantial features get added on sub-versions often enough that it's not going to be practical to use tags to distinguish this information.
In the cases where it's relevant, I think we can just ask users to clarify in the body of the question which version they're using, and otherwise adopt the working assumption that they're on the current version.
For reference, here are the main things that changed in Unity 5:
New lighting model with physics-based materials used by default. A
pbr tag might be more helpful here, as well as applicable outside of Unity contexts.
Realtime global illumination using Geomerics Enlighten. There's already a global-illumination tag users can add to highlight issues with this. It doesn't distinguish the realtime case, but neither does the
unity5 tag since the engine supports offline baking too.
HDR reflection probes, likely to be mentioned specifically in the question if the user is having reflection problems.
- StateMachineBehaviours for handling animation callbacks in a more structured way.
- Transitions between state machines & Direct Blend Trees (should be clear when used in the question)
- Ability to generate & adjust root motion curves.
Audio Mixer, allowing more control over audio levels for groups of content, and dsp effects. The pre-5.0 workflow still works the same if the user doesn't create an audio mixer, so only a description of their setup will tell us whether this is in play.
PhysX updates, but the physics engine is treated as a black box anyway...