It's their driver, of course they get to decide which devices it can talk to. Just like Xilinx can decide whether or not their tools will program Altera FPGAs. Even if the protocol was the same and technically it could, it's perfectly within their rights to design it so that it doesn't.
Apples to oranges, and you know it.
You're right, it's not a good comparison, because in my example the Altera device just happened to be compatible. A better comparison would be if Altera
intentionally designed their products to impersonate Xilinx devices, so they could piggy-back off of Xilinx's toolchain and not have to develop or maintain one of their own. You can bet your ass if they tried to pull something like that, Xilinx would try to find a way to block it, and nobody would be surprised (well, I would think so, but after reading this thread I'm not so sure there wouldn't be a group of people asking for the Xilinx CEO's head on a platter).
Actually, this brings up a good point. I want you to explain to me exactly what you think FTDI is accomplishing by making their driver not work with/brick/spit bad data out in the first place.
Easy, and I've already said it many times before.
Q: Why are they trying to make their driver not work with counterfeit chips?
A: To discourage cheap manufacturers from using counterfeit chips, and ultimately, to discourage the counterfeiters. Do you really think the counterfeiters are going to just keep up this cat and mouse game? Why on earth would they do that when they can just start counterfeiting a different manufacturer who doesn't try to restrict the use of their driver? As you and others have said many times, FTDI USB-UART bridges are nothing special these days, so why are you so insistent that the counterfeiters would keep dumping time and money into running around driver restrictions when they could just move to somebody else? That's FTDI's goal, discourage counterfeiters enough that they move to another target.
Q: Why are they throwing out "bad" or "garbage" data?
A: First, it's not "bad data", "bad data" would be if they made random changes and spit out nonsense. It's not bad data, it's a message, a very clear message explaining why it's not working. The alternative would be to send nothing and bury an error code or message deep in the bowels of the system logs where it will never see the light of day. It's a valid alternative, but FTDI must have weighed the options and made the decision that it's better to send out a very clear message where anybody using the device will see, risking the fallout from a few devices that might misbehave when it receives data it doesn't expect, but significantly reducing debugging time by affected manufacturers. They probably made the assumption that affected manufacturers WANT TO KNOW that they have a counterfeit device in their product, and the easier they can make that discovery the better. It doesn't really matter for the end-user, because the device has to go back to the manufacturer anyway.