Oh and excellent news about Begin/End pairs. Now we can start on the other things that are not supported by GLES, such as QUADS and QUAD_STRIP. I think that is the main thing likely to lead to a compile failure against ES1.
QUAD_STRIP is not much of a problem. As long as the number of vertices is even (which it should be anyway), identical behaviour will be produced by TRIANGLE_STRIP. If the number is odd, TRIANGLE_STRIP will add a spurious triangle on the end, but that would be a problem in the vertex data so I hope it isn't there. It should be easy to implement, anyway.
QUADS is trickier. Each QUAD can be replaced by two triangles, either in TRIANGLE_STRIP or TRIANGLES mode, but the vertex order required is different in each case, and 50% more vertices are required (repeating the first and last vertex for TRIANGLE_STRIP to flush the vertex buffer between quads, or repeating the middle pair in TRIANGLES to butt one half against the other). I suggest using TRIANGLES because it means less work for the GPU, since it doesn't have to delete the degenerate triangles.
As an aside, POINTS is always implemented by point-sprites on GLES. This may or may not matter, we'll see. Possibly, many previously valid uses of QUADS can be replaced by point-sprites - I'm thinking of the radar here.
In a couple of places, the polygon mode is set by external data. In these cases, a stopgap solution might be to dump a warning to the console when QUADS is used, and then just render with TRIANGLE_STRIP for now. This should produce halfway sane but obvious rendering artefacts to tell us that it needs to be fixed properly. We can also breakpoint on the console print call to figure out where the request is coming from.
The other major task is to rework the startup code to obtain a GL context via EGL. EGL in turn requires a valid framebuffer handle to attach to, the precise form depending on the EGL implementation (ie. could be a Broadcom DispmanX handle on the R-Pi, an X11 window where X11 integration exists, or at least two other ways of attaching to fbdev). This would be a good opportunity to introduce a configure flag and #define to distinguish ES builds from normal GL. Note also that normal GL contexts can be obtained through EGL too (where a full GL implementation exists on the platform), so we can test EGL separately from GLES.