Is there any good reason to merge a short-term, tagged change in the software?

Is there any good reason to merge a short-term, tagged change in the
software?

Suppose I've got some software whose last released version is 1.1.
Development from there has continued on two tracks:
Normal updates on master
Temporary changes meant to be released for a while as version 1.2, but not
included in any subsequent versions. For example, imagine an april_fools
branch.
My plan is to tag the temporary code as v1.2 and release it, but never
merge it to master. This is because if I did merge it:
I'd have to to deal with merge conflicts
Once all was resolved, I'd want to revert all of that temporary code anyway
Version 1.3 would be tagged and released based on the latest commit on
master when the time came.
This seems like the cleanest solution, but I'm a little hesitant. Should I
worry about having a lineage of commits where versions 1.1 and 1.3 have no
intervening commit tagged 1.2? Could this cause confusion for later
developers looking at the commit history?