Generally, I would go in the direction of what Dennis Barton suggested: a research note. That's usually sufficient. I think that can be the best way to ensure that similar profiles, once disambiguated, don't get entangled or mashed together again. Here's my example: Eilbeck-9 & Eilbeck-10. Those men (and their wives, Mary & Mary Ann) were mashed together on other sites, which made for some confusion. Surely not as confusing as your situation
But since this is 14 very similar men, I think that your initial route is probably better, provided that it's linked on each of the profile pages:
a free space page to document all the different men
One additional work-around type solution that may help. The real risk is the loss of data in merges. So I'd suggest ensuring that the "final" version of each profile is archived in the Internet Archive's Wayback Machine, then also link those archives on the Free Space Profile that you've made. That way, if the information is merged away, a future genealogist might find not just breadcrumbs that you've left behind, but the whole of your research in the Internet Archive.
Still, you're concerned, and I understand why:
I am concerned that once we get this all cleaned up, someone will see those false lineages on other sites, start merging profiles and we will be right back where we were.
In my view, the real issue is that many folks on WikiTree (and elsewhere) aren't very conscientious in their quest to contribute. Provided that your documentation was thorough and convincing, this would not be a problem if people acted conscientiously, taking the time to read the profiles and check the logic. So your proposed solution seems to be creating a barrier to stop any reckless or non-conscientious behaviour:
What I would like to propose is that there is a type of "rejected merge" that [is] "permanent". The error message would indicate that a leader has to remove the rejection. Does that sound like something we should think about?
It's an interesting idea. I would suggest that it might be better described as "locking" a rejected merge. That isn't "permanent", but rather requires a key to override the lock.
I would ask, what criteria and/or procedure would need to be met and followed in order to make the rejected merge? And, likewise, what criteria and/or procedure would need to be met and followed to "unlock" a rejected merge?
So yes, I could see utility in your suggestion. But there's a question of how it would be applied.I don't have a good metric or threshold, so perhaps you can address that.
P.S. Sounds like you've put on a valiant fight and have earned one of these.