USB2 is backward-compatible with USB1.1. USB2 specifies that all USB2 devices must support the requirements of USB1 and negotiate them appropriately. To put it another way, USB2 is a superset of USB1; it includes as a requirement the exact communications protocol of USB1. It does not emulate USB1. A USB2 device could perhaps be described as being able to emulate the behavior of a USB1 device, but USB2 does not emulate USB1. It implements USB1 directly as a requirement of the specification.
The closest thing I can think of to "protocol emulation" are network testing systems. There are systems that pretend to execute a network protocol to test that all the transmission equipment handle that transmission correctly. I use VOIP testers, for example, that generate something that appears to be SIP call traffic from one end of a network to another. These are often colloquially called "protocol emulators" in that they appear to implement SIP or H.323 but don't really: the two end points are talking gibberish and not really even listening to what each other is saying except for the minimum necessary to keep things like session state and round-trip lag elements of the protocol valid.
In a sense its a form of "protocol emulation" in that its reproducing the behavior of a system relative to some standard (that standard being what intermediate network gear sees) but its not really emulating the protocol itself; its emulating the network characteristics of the protocol for test purposes.
If what's bold, that is what you say, is not saying "USB2 protocol requires all devices to comply with protocol USB1", and so, "USB2 protocol incorporates protocol USB1 and more" that is, "USB2 imitates USB1 and exceed it", then I'll be damned.
I'm going to propose the definition in
Wikipedia's article on Emulators, which stipulates that "In computing, an emulator is hardware or software or both that duplicates (or emulates) the functions of a first computer system (the guest) in a different second computer system (the host), so that the emulated behavior closely resembles the behavior of the real system. This focus on exact reproduction of behavior is in contrast to some other forms of computer simulation, in which an abstract model of a system is being simulated. For example, a computer simulation of a hurricane or a chemical reaction is not emulation." So, as long as the intent is to provide an exact reproduction of behaviour, of which we have had countless examples an we even know the majority of the rules, then yes, we can have an emulator of City of Heroes, as long as the people who have the best knowledge of it are behind it, and as long as it was a human-created system, it can be recreated to fool every other human as being the real thing.
And I think we've just got the kind of person quoted in this post, the rest of this kind must already be on Titan board, and the kind that can't help us because of NDA shouldn't count.
If the problem is the server's input file being an unknown, that's partially correct. Those are not unknown, they are variables. Emulation doesn't care to emulate every data it's going to have presented, it copies the mechanism. Saying a "community server" can't be an emulator because we will never have the server data files is like saying you can't have homebrew on the PSP because we couldn't read what was on the discs. We all know the data that was in the server files, the only problem being we don't know their format is moot. When you plug an MP3 player on a pair of speakers, they don't care if the format was in fact Ogg. The output is the same. That's the same with CoH client and a community server, wether it's an emulator or a reimplementation is the same - the game is supposed to function the same.
Maybe the cruelest fact would be that the server files are forever gone. So no developer will never have to ever bother with making what would truly be considered an "emulator" because there is nothing to emulate except the whole server and its data altogether. Then isn't that an emulator ? It also transforms raw power into client-compatible data ! We reimplemented all the mechanisms necessary to produce the same output, and it will have the same input: the client commands and raw power.