Update: The cracks between 16x16x16 sections have existed for a long time, and still do. Crack theory has been, is, and will still be applicable. The lines that started to appear in between every block in the 1.5 snapshots and should be fixed in 1.5.1 were caused by texture coordinates overflowing their tile slightly in the rasterizer.

Crack theory

Cracks occur in rasterizers like OpenGL when edges that should align don't match exactly. This can happen if an inexact calculation is used, and vertices that should be the same end up in slightly different places. The errors may seem minuscule, but they invariably result in severe flickering along the cracks. The rasterizer will miss a few pixels and fill others twice. Using different OpenGL transformations to move different vertices to the same place counts as inexact:

glRectf(0, 0, 1, 1);
glRectf(1, 0, 2, 1);

glRectf(0, 0, 1, 1);
glTranslatef(0, 0, 1);
glRectf(0, 0, 1, 1);

The former will always, unquestionably align. The latter will have a crack. While associativity would tell us that both examples are the same, rounding error does not succumb to associativity. 32-bit floats are exact for integers in [-2^24, 2^24], scaled by a power of two. 64-bit doubles reach a whopping 2^53. If both operands of an addition are round enough (in binary), the result will be exact. This would be typical for code like the first example. Rolling the same addition into a transformation matrix will almost certainly be inexact, because the matrix is polluted by everything else in it. Really the only way to get it right is to perform a separate addition before the matrix.

If you perform the addition in a vertex shader, keep it separate and it should be okay, save for the hypothetical implementation that optimizes both into a matrix (if they're still technically allowed to optimize willy-nilly nowadays):
Edit: Uniform state is slow to change, so an attribute used like a uniform would likely be faster than a uniform.

uniform vec3 translation;
void main() {
    vec4 vertex = gl_Vertex;
    vertex.xyz += translation;
    gl_Position = gl_ModelViewProjectionMatrix * vertex;
}

What's cool about this is that even if you're very far from the world origin, you can still keep everything that matters exact. It also doesn't have a stepping or distortion problem in the Far Lands. The CPU code should do something like this:

dvec3 camera;
dvec3 roundedCamera = camera.roundToMultipleOf(16); // Assuming your world transformations are normally a multiple of 16. Can be demoted to float if you stay within 16 * 2^24 blocks. This is half of the magic, by reducing the translation fed into OpenGL to almost nothing.
dvec3 difference = offset - rounded; // Not critical and rather small; can be demoted to float, and will be when fed to OpenGL.
// Substitute difference for camera when calculating the camera transformation.

Then, before drawing each batch:

dvec3 translationOfBatch; // Can be float if roundedCamera can be.
dvec3 translation = translationOfBatch - roundedCamera; // This is the other half of the magic. Two potentially huge numbers are reduced to a small, exact multiple of 16. Can certainly be demoted to float, and will be.
// Load the uniform.

I hope this is enough theory to help you understand and fix cracks. Now, on to the actual problem description:

Description

Previously, cracks would only appear in between 16x16x16 sections. Not as it should be either, but hardly worth reporting. In the latest snapshots, however, they appear in between every single block. That is too much.

The screenshot shows a superflat world with preset "2;7,62x0,49;2", viewed from below. It should be viewed at its full 1920x1200 size to see the speckles. Incidentally, Minecraft thinks it should light the underside of the obsidian when I get close to it.

Addendum: textures?

After noticing the directionality of the cracks, I realized it's crossing over into adjacent tiles on the texture. That could explain some or all of this bug. I will upload a second screenshot demonstrating that. It's of a similar superflat world, but using purple wool (35:10) instead of obsidian.

What you see is a close-up of the vertex joining four blocks. You can see some yellow seeping through one edge, and blue through the other. Indeed, those are wool blocks adjacent to the right and below, respectively, in stitched_terrain.png generated by an older snapshot. There is also some sky showing through next to the blue wool (I know it's the sky because it becomes black at night). I'd expect it to be orange wool as that is located above it in stitched_terrain.png, but then that file is probably outdated. It may well be that the adjacent texture is transparent. Indeed, green wool doesn't have this 'crack'. Texture coordinates should be the only difference between wool colors, therefore this should be responsible.

Older versions of Minecraft used to move their texture coordinates inward just a tiny amount to avoid this issue. Was that tweak removed when the rendering engine was overhauled?