As an aside note, legally, Mesa is not OpenGL; rather it is a free implementation of the OpenGL API.
In any case, Mesa was written to support hardware acceleration. However, it had nothing for synchronizing with the underlying operating system or with any other graphics card state management environment (such as X11), and so in its basic state, Mesa itself could only be used for hardware-accelerated OpenGL under platforms such as DOS and Windows where ensuring that it is the only thing accessing the video card at any time is a trivial task.
However, the first hardware-accelerated driver for Linux, fxMesa, was an important exception to this rule. The original 3Dfx Voodoo accelerator (as well as the Voodoo2) was designed as an add-on card for existing 2D graphics cards. As a result, its state is completely separate from the 2D card's, and so for fullscreen-only OpenGL, supporting the 3Dfx through Mesa was also trivial. In addition, there was a hack which copied the Voodoo's framebuffer into an X pixmap and then blit the pixmap to the screen, but this was quite slow due to the numbers of large memory copies which had to take place across various buses which weren't intended for large memory copies.
3Dfx did put out a video card called the Rush, which was both a low-end 2D chip and a Voodoo on a single card with a dedicated memory path between the 3D framebuffer and 2D blitter. The Rush's X server had a specific extension which allowed fxMesa to perform its memory copy as quickly as any other image blit, so on the Rush, fxMesa could be used for proper windowed OpenGL. However, there were still many issues; only one hardware-accelerated OpenGL program could run at a time (there was no synchronization between processes, and so context management became, well, voodoo), and the Voodoo architecture didn't allow for much flexibility to begin with.
One interesting thing to note is that fxMesa typically used a kernel module to get the low-level access to the 3Dfx hardware. Through the /dev/3dfx device, a single program could lock the hardware and have full control over it. This prevented other programs from clobbering the hardware, allowed for clean release even if the program died ungracefully (such as through a segmentation fault or kill -9), and allowed for some degree of safety and stability while still giving fxMesa direct access to the hardware without giving it root access to the system. (Without /dev/3dfx, programs using fxMesa required root access to operate, much as the X server does.)