Scientists used to use anagrams to register scientific discoveries without revealing them. Hooke registered his law of elastic extension using the letters "ceiiinosssttuv”, which he later revealed to unscramble into "ut tensio, sic vis" ("as the tension, so the force").
People did try to brute-force the anagrams. On two occasions, Kepler unscrambled analgrams from Galileo into the statements that (i) Mars has two moons and (ii) Jupiter has red spots. Bizaarely, both turned out to be true facts, but not what Galileo's anagrams were about!
This reminds me of fixing a bug that causes your problem but then you discover the problem persists after the fix and that you actually had two independent bugs causing the same problem.
Erm, if you do a fix and the problem still exists then how is that a fix? For example, if I have a number box and I punch letters in it and the problem is <string "CARTER" is not a number> error is still poping up, then my fix is not a fix, is it?
Regardless of how many bugs I have that cause the problem, a fix, in my opinion, is the sum of all those bugs going away.
That is a very project managery view of things. And in a simple system you might be right. In a complex system multiple different things can cause same looking problems.
Let's say you are not working on a "number box" (whatever that is) but a drone airplane. Your costumer reports that the drone become unresponsive and crashed.
You investigate and find that there is a buffer overflow which sometimes gets triggered in the navigation system which trashed the memory and lead to the loss of the drone. You develop a patch, and additional testing etc etc and you deploy the fix.
A year later a drone crashes again. You do the investigation and this time you find in the engine control there is an edge case which causes it to shut down the engine under rare circumstances.
Was the first fix not a fix? If I correctly interpret you it wasn't because the "drone becoming unresponsive and crashing" problem still persist. Obviously that is not a useful way to look at the work if you actually have to develop the fixes.
Obviously there was two different problems, and they both need fixing separately (often by different teams). Just because you are not aware of the second bug when you deploy the first fix doesn't make the first fix not a fix.
Of course you might say in this hypothetical the "problem was not the same" but you only know that after you have investigated. If there are no reasons to suspect the second bug, and during the testing of the first fix things appear to be working you have no way of knowing that.
I see your point which is semantically valid. But there is something more to it. Consider it from the other direction: You can introduce a bug by making some modification to the code. Then you add another modification which produces the same erroneous behavior. Either one alone would be enough to cause the problem. And two of them together does not cause any more problems than each of them alone.
But now to "fix" the problem you have to undo both of your modifications. You have 2 bugs and you have to "fix" them both. "Fix a bug" as in "Kill a bug".
So "Fix a bug" can mean "remove a cause of the problem". Or it can mean "remove the problem".
Obviously it'll be a bit contrived for this example, but... Suppose the logic that checked whether the input was a number used the hardcoded string "CARTER" rather than the value from the input. And, totally independent from that, your error display code just displayed the hard coded "example" value '"CARTER" is not a number' regardless of whether the state was correct or not.
In this case, I would say you have two bugs. First, that you aren't evaluating the actual input data and second, that your error checking code is not running correctly but just defaulting to the same value all the time. Bugs are distinct problems with your code, not problems that the user encounters and you have two distinct problems with your code.
I used to play a social deduction game on IRC, and this was one method to reveal things without revealing them.... but it was too powerful so was banned sort of.
There is also spyfall (https://boardgamegeek.com/boardgame/166384/spyfall) which is about one person not knowing what everyone else knows and trying to pretend otherwise. Very popular among my friends.
Excellent party/social game. An additional variant we play with is to create an "Oops, All Spies" deck to throw in the random selection. Everyone believing that they are the only one who doesn't know the location inevitably leads to hilarity.
Sounds like a regular game of mafia or werewolves, which basically just requires someone to run it and some means of communication, whether it be in-person, IRC, forum, or some other chat application (there are more 'formal' versions of it in the form of board games or video games, like town of salem, as well).
Picked up Town of Salem recently. Quite a fun game. Have been pleasantly surprised with a good experience even with random other people most of the time
People did try to brute-force the anagrams. On two occasions, Kepler unscrambled analgrams from Galileo into the statements that (i) Mars has two moons and (ii) Jupiter has red spots. Bizaarely, both turned out to be true facts, but not what Galileo's anagrams were about!