Regarding TwoIsAnImpossibleNumber (see also the ZeroOneInfinityRule), there seem to be some situations where two is perfectly valid, but ThreeIsAnImpossibleNumber?.
Take a chat application for example. Chatting with zero or one participants makes no sense, but chatting with two or more makes perfect sense. The problem is that the difference between two and more-than-two is not trivial - with two participants passing messages, distinguishing different participants' responses and connection/disconnection is a simple task. Handling more-than-two participants requires using either a client-server or traditional multiuser peer-to-peer design, causing complications in the areas of message propagation, message ownership identification and client connection/disconnection. It seems that the concept of a two-person chat application cannot be considered a special case of a multi-user chat application, as the extra generality requires a fundamentally different implementation.
Is this then an exception to the TwoIsAnImpossibleNumber rule, suggesting that in certain situations TwoIsNotAnImpossibleNumber as there may be a non-trivial jump between two and three?
Perhaps this case should be refactored from "2 chat participants" to "one other participant". Then the step from 1 to 2 is pretty much the same as the step from 1 to *.
I believe an appropriate interpretation for the specific case of chat is this ...
chat with exactly one connection is simple, giving two participants. chat with three participants (i.e. more than one connection) requires solving a harder problem. In this case we shouldn't specialize to exactly three participants - that would require an ad hoc solution. Instead we should solve the more general problem of an arbitrary number of participants. You can have zero or one connection, but exactly two connections is a special case and should be eschewed in favour of solving the problem properly.
Viewed in this way, chat is not a counter-example to the assertion that TwoIsAnImpossibleNumber.
Since TwoIsAnImpossibleNumber comes from the ZeroOneInfinityRule, perhaps it's better to say that Succ(Succ(Base)) is an impossible number.
In the case of the chat program, 0 people in the chat is not the base, because the user running the program is always there. From that point of view, the rule holds, as Base is Notepad, Succ(Base) is One-to-One, and beyond that is One-to-Many, which might as well be generalized.
A binary tree, in which each node can have up to 2 children, seems like a better example.
But then again, not quite... at each node we're faced with making one decision... are we going left or right? Once we have three nodes, we've got a n-comparison problem, and solving the problem for exactly two decisions is not much easier than solving it for n comparisons. In other words, two is an impossible number: if you're counting two, you're counting the wrong thing :) -- WilliamUnderwood
"Allow none of foo, one of foo, or any number of foo. ... The logic behind this rule is that there are often situations where it makes clear sense to allow one of something instead of none. However, if one decides to go further and allow N (for N > 1), then why not N+1? And if N+1, then why not N+2, and so on? Once above 1, there's no excuse not to allow any N; hence, infinity."
So why not ThreeIsNotAnImpossibleNumber? And then why not FourIsNotAnImpossibleNumber? Hence, InifinityIsNotAnImpossibleNumber?.
There is a StrangeLoop in there if I think about it too hard.