> All it would take is a few extra modulation and coding modes in the standard. [...] but at a data rate of 0.3 kbps.
It would take more than just "a few extra modulation and coding modes". At 0.3 kbps, even a single 100-byte packet would already use up one whole third of the available airtime for the channel. (On the current slowest WiFi speed of 1 Mb/s, that packet takes a fraction of a percent of the available airtime, and even that's slow enough that some newer APs disable the older 802.11b speeds by default and set the slowest speed to 6 Mb/s.) And due to how the WiFi protocol works, each AP periodically (usually every 100/1024 seconds, so around 10 times per second) broadcasts a beacon at the slowest rate it accepts (and AFAIK the beacon is nowadays larger than 100 bytes).
It would probably require at least changing how the clear channel assessment works, to allow for overlapping transmissions, but that's a fundamental part of the standard. Once you're going that far, it probably makes more sense to define a new protocol, one better tuned for that use case.
You'd probably simply have to define that beacons are still sent at 1 Mbps, but define a new 'beaconless' mode which can connect and work from a long distance away without the beacons.
It would take more than just "a few extra modulation and coding modes". At 0.3 kbps, even a single 100-byte packet would already use up one whole third of the available airtime for the channel. (On the current slowest WiFi speed of 1 Mb/s, that packet takes a fraction of a percent of the available airtime, and even that's slow enough that some newer APs disable the older 802.11b speeds by default and set the slowest speed to 6 Mb/s.) And due to how the WiFi protocol works, each AP periodically (usually every 100/1024 seconds, so around 10 times per second) broadcasts a beacon at the slowest rate it accepts (and AFAIK the beacon is nowadays larger than 100 bytes).
It would probably require at least changing how the clear channel assessment works, to allow for overlapping transmissions, but that's a fundamental part of the standard. Once you're going that far, it probably makes more sense to define a new protocol, one better tuned for that use case.