(Excellent implementation, by the way. But...)

There's an annoying UI difference between your version and the Windows version. I'm in the habit of pressing both mouse buttons while pointing at a number to clear the surrounding squares if there are already the appropriate number of mines marked; this is required by the original Windows implementation, a left-click on its own does nothing. In the original, if the number of marked mines is incorrect it 'presses' the surrounding squares down. In yours, this happens when the left mouse button is pressed, but they pop up again when the right button is pressed; the observed behaviour therefore depends on whether the intended simultaneous button press was actually left-right or right-left.

It was a deliberate choice to require only the left button to do this: on my preferred type of trackball left-and-right-clicking is annoyingly unwieldy, and my Minesweeper solution time has dropped by about 30% just from this one UI change. (The trackballs are fantastic for most things, but the traditional Minesweeper UI seems to be the one common thing they're not good at :-)

Mouse handling is done centrally in my puzzle framework, and as you observe the pressing down of one mouse button fabricates a button-up event for any previously pressed one. This is usually a good thing, though I concede that it isn't ideal for Mines. Feel free to submit a patch :-) The relevant function is midend_process_key() in midend.c. All it'd take would be a bit of configurability in that function and a set of flag bits provided by the individual game.

Actually, that turned out to be quite easy to fix. r5888 should be fine.

Excellent, that appears to do the trick.

Next bug report: click in the window, outside the puzzle area (under Linux):

mines: mines.c:1295: mineopen: Assertion `x >= 0 && x < ctx->w && y >= 0 && y < ctx->h' failed.

(More generally, clicking outside the puzzle results in strange "you've lost" states.)