Updated Feb 10, 2003 - Corrected explanation of the short preamble problem.
Part of the frame that is transmitted by an 802.11 station is called the preamble. The original 802.11 specification (which defined only 1 and 2Mbps operation), defined only a long preamble that uses a 128 bit sync field. When the "high rate", i.e. 11Mbps, 802.11b standard was created, an optional short preamble using a 56 bit "sync" field was added. This was intended to improve the efficiency of the wireless network for more "real-time" applications such as streaming video and Voice-over-IP telephony applications. Figure 1 has the gory details on the two preambles if you're interested.
All 802.11 devices in the 2.4 GHz band, including 802.11g devices, must be able to transmit and receive long preamble frames. 802.11g devices are required to be able to transmit and receive both long and short preambles, but support for short preamble in 802.11b devices is optional.
The problem occurs when an 802.11g AP allows the use of Short Preamble by the stations it communicates with (also known as its BSS - Basic Service Set). The AP may also choose to allow legacy stations that do not support Short Preamble to associate with the BSS. If both these conditions are allowed, the legacy stations that aren't short-preamble-capable will not be able to understand much of the communication in the BSS, and most importantly won't be able to receive the all-important "Protection" frames. This could result in legacy 11b stations transmitting at the same time as 11g stations, which doesn't help either one to properly get their data sent!
This 802.11b interoperability problem has been noted in recent articles on draft-802.11g, but it looks as though it may be getting somewhat overstated. First, the short-preamble problem affects only a subset of the 802.11b products in the field. Specifically, ORiNOCO and Symbol cards and those using the Intersil PRISM 2.0 and Agere Systems chipsets.
Second, manufacturers may already have incorporated a fix for this problem into their AP code. (I've used both ORiNOCO and PRISM 2.0 based cards in my testing and have yet to run across the problem.) And finally, another reason to relax is that I'm told that the IEEE Task Group g committee will probably address this issue in the 802.11g standard after some additional debate.