I'd be surprised if there is a way to get true "client-mode bridging" to work without some kind of layer 3/proxy-ARP-esque solution. I believe that the problems that people are seeing with this method of wireless bridging has to do with a limitation in the 802.11 spec, and is not specifically a limitation of the WRT54G hardware or the OpenWRT software. Basically, as I understand it, an AP knows where to send a packet to by looking at the MAC addresses that clients used to identify themselves TO the AP when they registered/associated with it. So, if the wireless client identifies itself with its own MAC and then tries to "bridge" ethernet traffic over to the AP, the AP is going to be receiving ethernet frames which bear MAC addresses that are different from the one that the AP knows the wireless client by. If someone else connected to the AP tries to send traffic to one of the devices plugged into the "client bridge", it will prepare an ethernet frame with the target MAC address being the device it wants to talk to, *not* the wireless client. Once that packet reaches the AP, it doesn't know what to do with it because there ARE no clients associated to it with that MAC address. The associated stations list *IS* the AP's learn table. In some cases/implementations, the AP may not even bother accepting packets from a wireless client to begin with if the MAC in the ethernet frames it is receiving from it does not match the MAC that the client used to identify itself by to the AP during association.
I work for a wireless ISP, and the equipment that we use to connect our clients to the APs on our towers have solved this dilemma in one of two ways, traditionally:
1) The wireless client "clones" the MAC of the first ethernet device it sees behind it, associates to the AP using that MAC, and then bridges traffic back-and-forth between the AP and that ethernet device ONLY. If it sees the MAC change on its ethernet interface (either because someone plugged in a different device or because there are multiple devices behind it), it will re-associate using the new MAC so that it can bridge traffic to THAT device.
2) The wireless client associates to the AP using its own MAC and then does what we like to call "MAC-NAT": it maintains an internal layer 2 "NAT" table that maps this IP address to this MAC address, and then re-writes the ethernet frames as they're going out to the AP so that they all look like they're coming from the wireless device itself. When a packet comes in bound for a certain IP address, it consults its "MAC-NAT learn table" to detemine which host on the ethernet side of the bridge the packet should go to, and re-writes the packet accordingly before sending it on.
Neither of these are truly "ethernet bridges."
From the sounds of it, the Linux bridge device coupled with the Broadcom wireless driver in client mode is doing something similar to #1 above; that's the only way I'm able to explain why pings come back from all hosts, but only from one-at-a-time. It'd be interesting to see what is going on during these "ping tests" from the AP's perspective: is the MAC of the WRT54G "changing" to match the MAC of the host that you are seeing ping responses from at that given instant?
I don't know too terribly much about WDS itself (it's something we've never felt the urge to put into production anywhere on our network; our backhauls use more robust wireless solutions, and 802.11 is simply the "last-mile" hop to the customer), but I'd guess that it was drafted up precisely because bridging devices behind an 802.11 client -- with the way the standard is written up -- simply doesn't work without some magic involved, and so another solution for effective "wireless bridging" was needed. Thus, if you want a REAL ethernet bridge over 802.11 links, you'll have to go with WDS. Otherwise, if you want multiple hosts behind the client bridge, you'll need to set up Proxy-ARP and use it as your "MAC-NAT" solution.
Hope this helps,