Wi-Fi (IEEE 802.11) is not ethernet (IEEE 802.3) Ok, I've just changed part of the question to avoid this confusion. Now, completely off the topic, just to think about it: several products are advertised as 'wireless ethernet LAN'.

I have seen such things, but that doesn't mean it is correct. Wi-Fi and ethernet frames are different, and ethernet uses collision detection, but Wi-Fi uses collision avoidance. Other LANs use things like tokens to prevent collisions altogether. They are all different LANs, and some advertisement doesn't make them the same thing.

that doesn't mean it is correct. Ok, I agree with you. Thanks to correct me. I'm aware of such differences as CSMA/CD, CSMA/CA and tokens. However, I was blinded by ads like 'Wi-Fi is the wireless ethernet LAN'.

nor can you expect it to run over any routers There will be no routers, switches or bridges, only point-to-point communication. I've just edited the question to avoid this confusion.

you are basically going back to serial communication All I need is pass messages (ASCII characters) very fast. The rest let the application layer solve it.

Even serial communications need controls, but those are provided by extra hardware lines that must be emulated in network communications software. There are HSSI, USB, and FireWire for that sort of communication. I think you are trying to reinvent something.

must be emulated in network communications software Maybe I'm missing your point, but the articles I've mentioned in the original question provided the source code and, at least for Ethernet, it isn't complicated. Do you consider that coding the same for Wi-Fi would be much more complicated?

If you are not going to use frames, then you will not be able to take advantage things like the flow control that the hardware lines or frames provide. How will you deal with wireless interference, and how do you give back the airwaves to allow other communications so that you don't interfere with others, etc.? There are all sorts of things to consider. Your source code for ethernet probably uses ethernet framing, otherwise, as @RickyBeam says, it's not ethernet.

You need to understand that Wi-Fi is a half-duplex technology since a radio can't send and receive at the same time. Somehow, you need to put in some controls to let one side acknowledge correct receipt so that you can continue or start over. Packets are useful for this since you can resend smaller pieces. Especially with a problematic medium like the airwaves (interference) because you can't control the airwaves, you need to do all sorts of error and collision detection and be able to request data to be resent. You are basically reinventing what has been done and proven.

you will not be able to take advantage things like the flow control Good point, I was hoping someone raise this issue. I don't want to avoid using frames, I'm just considering to avoid using the MAC header. I'm not sure yet what the consequences would be. But if this means that I can no longer use features of the MAC sub-layer it is a NO GO. However, if this means that only features of the LLC sub-layer would not be available (ie: multiplexing and sliding window), I guess I can handle this in the application layer.

a problematic medium like the airwaves (interference) As far as I know interference and multipath propagation are handled directly by the hardware. Frames without the MAC headers would not change this features. Please, correct me if I'm wrong.

It's not exactly handled in hardware. You will need to use drivers that support your new network stack, and that will require you to write driver software to handle these sorts of things. MAC headers are actually very small, If you look at ethernet, they are only 14 bytes for the header, and 4 bytes for the FCS (which you need to validate the integrity of the frame). The Header part is less than 1% per 1500 byte payload for ethernet.

You really are reinventing the wheel for what you want to do.

Any LLC sub-layer or anything in the network stack above the hardware will need to be written from scratch, including any application interfaces.

@YLearn You would need to write your own L2 protocol to work without the L2 headers Ok, I really wasn't sure about that. However, it sounds a little bit cumbersome to me. It should be possible to use, for example, the media access control protocol without the MAC headers. There is no relevant information there actually specifying how the media access control protocol should behave (idle time, schedule backoff, abort transmission ...). I could make a similar case for bit stuffing. My guess is that this is a trade-off between flexibility and efficiency. It's tough to have both.

@RonMaupin reinventing the wheel I really would like to avoid reinventing the wheel. The perfect solution for me would be calling the L2 protocols (bit stuffing, sliding window, media access control, multiplexing, ...) without using the L2 headers, which sounds reasonable to me due to the aforementioned comments with YLearn. However, if this flexibility is not currently available, there is no problem. I can send the frames with the standard MAC headers.

how does one host actually send to another host without the layer-2 address in the frame There are several ways to overcome that without using the MAC addresses burnt inside the network cards. Unfortunately, however (based on the @YLearn answer), it seems that the current hardware doesn't allow you to send a frame without the standard L2 headers (ie: with MAC addresses).

@RonMaupin that will require you to write driver software I've just posted a similar question but focusing on the software side: WiFi Beacon Packets. I guess it was not suitable here on 'Network Enginnering'.