Eventually it all comes down to physics. We can manipulate it as much as technology allows, but in the end... physics. The problem with running a single channel is interference. You introduce interference when all APs and clients attempt to communicate on the same channel. Meru's major asset is modifying certain values in duration fields. Think of wireless as a hub. Everyone tries to communicate at the same time. When there is a collision it stops and retries at a random interval. In wireless there is a value inside the packet (NAV value) that tells all the other devices how large it is in essence to attempt to prevent someone else from thinking the channel is clear and sending data. Meru artificially inflates this number for its clients and thus can act as the conductor of your wireless orchestra. In theory, this will allow the system to tell which client when it wants to communicate with it and keep the channel clear from crosstalk. In practice, you have some serious limitations that Meru doesn't tell you about.
First, you are only using one channel for your network so no matter what you are limited to the maximum transfer rate of a single channel (or two if using dual band) as if you were the only client. This limits the maximum device density on your network. Secondly power of transmissions become very important. Third, you are putting even more network performance into the hands of wireless nic developers who may not properly test in the proprietary method that Meru uses the 802.11 protocols. Remember Meru only makes up 3-4% of the wireless market share, their proprietary tricks may not be fully supported, especially on legacy devices or BYOD products. If you search the internet you'll find many problems people have with new firmware releases, new nics, dated nics, of all manufacturers including big names like Intel which work by default on other wireless networks. It also creates problems for adjacent wireless networks attempting to use the same channel as the Meru network because they are seeing the traffic and the modified NAV values and thus the Meru system can bring their channel down or prevent proper traffic flow. Definitely not a good neighbor as well should all be using the unlicensed wireless spectrum that must be shared with others. Also, Meru used to broadcast the same SSID and wireless MAC address to the entire network which ended up causing some serious problems with wireless NICs that didn't know how to use the network. So they now have a function where they broadcast a response SSID and MAC to individual clients giving each its own unique wireless network. This adds overhead in additional beacons and extra processing on the AP CPU and WLAN controller, thus reducing overall performance.
In terms of density, Meru released a video a couple years back showing they can put 500 devices in a single room and connect them wirelessly. What they didn't initially tell you was that they used many access points and a multi-cell approach using EIGHT 2.4 and 5.0 Ghz channels to do it.
Interestingly, this document says they used 8 channels: http://www.merunetworks.com/collateral/white-papers/2010-wp-wireless-lan-high-density-demonstration-500-clients-farpointgroup.pdf
Essentially they took a lot of time and money to produce a marketing piece that put 60-65 devices on a wireless channel. In the end, not very impressive.
So when you say "Meru is designed specifically with channel interference and high density of AP's in mind" you have to realize the reason they do this is because the system won't work on a single channel without attempting to mitigate normal traffic patterns. But there are tradeoffs. And when Meru wants to demonstrate high density deployments they abandon the single channel approach. The multi-channel blanket architecture becomes cost prohibitive because you would need additional access points to run on separate channels. Also, something to think about.. what happens when someone plugs in an interference device like a microwave or bluetooth? The network can't adapt unless you want to hop everything and all clients to a new channel.
This is not to say Meru isn't a good product (as long as you don't like your neighbors), it can do some interesting things with 802.11ac if a customer wants to use a single 160 MHz channel. I imagine most customers would prefer 40Mhz channels to expand their BYOD and wireless density though... as Meru used in their multi-cell high density demonstration. Interestingly their marketing documents say you should use a 160Mhz and it will support large client densities. Take their marketing as you will.
