Have you considered using voxel ray casting to speed up rendering?
We have assured access to OpenGL 2.1 since 1.7.10, and therefore have access to extensions.
It'd remove the need for the complex mesh baking system that has casual glitches (#278).

This is how it would go:

• If GL_EXT_geometry_shader4 is available:
  • Vertex shader: receives a single vertex (C&B block position).
  • Geometry shader: receives the camera direction in a uniform, copies it into a varying and emits upto 6 triangles of a cube at the block position.
  • Fragment shader: takes the varying, a sampler3D with the C&B voxels, a sampler2D with the block texture atlas and performs the ray casting. Notes:
    • The varying, being interpolated with perspective correction by default, takes the FOV into account.
    • I'm assuming each voxel contains the required data to address the block it describes (indirection texture).
• Else:
  • Vertex shader: receives a whole cube and the camera direction as uniform to be passed as varying.
  • Fragment shader: same as above.

Fragment shader concept.

Disclaimer: There could be other minor details that I'm missing out.

PS: I'd have preferred if Mojang used Array Textures, instead of texture atlases, to store all the item/block textures.

Generally thinking I'd imagine that this would probably be slower and more error prone then the existing system, it also requires re-implementing a considerable amount of logic with lighting, uvs, glowing faces, and more that are all internal to MC itself in a shader.

it also requires considerable testing and verification for hardware compatibility, it might make sense to try something like this if I was writing a full fledged voxel game with its own requirements and experiment with optimal rendering techniques where I can create one consistent pipeline for rendering.

But in the case of a mod for MC this just seems like a lot of work for likely very little gain and more headaches.

Let me address some points.

Slower? Not even by a flying chance.
We're talking about the GPU horsepower available to Minecraft that's currently underused.

The existing system is the one that's more error prone due to its complexity.

Regarding hardware compatibility, the baseline is OpenGL 2.1, which rules out all the people with crappy/integrated cards.
As a matter of fact, that extension was introduced 11 years ago with the GeForce 8 Series, and it requires at least OpenGL 1.1.

You know what I could do? Take matters into my own hands and implement the new pipeline myself.

Let me try and explain why I think the way I do, and I apologize that it got a bit wordy and detailed while I tried to articulate my reasoning.

On complexity,
Considering that most issues that C&B has with rendering are related to GL State, I'm not sure how this will mitigate that. The issue you linked likely is an issue because the blocks are being rendered as TESR, and another mod has probably changed the configuration of depth testing.

To use a shader for rendering all C&B rendering would have to be separated from the MC rendering pipeline which in my opinion is messy business. since it means copying constants and logic from the MC Codebase into the theoretical C&B Shader

On Compatibility,
Unfortunately is more complicated then which extensions are supported, some shaders won't compile on certain hardware, or preform worse on some hardware then others, hence why I speak of testing and verification. There is also the question of embedded hardware, complicated shaders even if supported tend to run quite slowly on such hardware. In my experience "standards" work great in theory, but not nearly so well in practice when different cards or chips all implement them slightly differently.

On Performance,
C&B's complicated nature has a lot to do with its ability to use other blocks, which have colors, textures, lighting. This means that for any given type of bit, there could be multiple layers each with their own UV coordinates, each with their own light value, each with their own color multiplier. UVs are different for each side of the block as well. each block has 4096 different bits, which means that the shader will need to be aware of these different details, which means generating various shaders or using uniform's to pass this data into the shader, or creating textures to pass data into the system. We'll need new data structures for storing these, and providing them, and this may or may not use a decent amount of ram, where the CPU variant compressing them only for a short time, some optimizations could likely be made by using smaller data types and using indirection by condensing data by unique state present.

I'm not sure how much work and effort you would need to apply to minimizing this, but in general with GL the largest performance impact has to do with state changes, changing shaders, texture bindings and uniform bindings can be quite costly especially if you have to do it often, which means sorting rendering by like states, uniforms, textures.

The shader which likely works very well for simple exists/not exists, even for colored voxels gets much more complicated when you talk about the amount of extra features that C&B has to support to represent other blocks, this complication is currently processed in geometry generation, since we need to forego geometry generation onto a shader, that means that level of complication is transferred from the CPU to the GPU, and with it the data required to make those decisions.

Is it possible I'm wrong, sure; I don't claim to be a guru of opengl and rendering, especially in more recent years where I've only dabbled in it with modding. And its possible that some of the elements involved have nice solutions at some level.

On the whole,
Of course your quite welcome to take advantage of C&B's open source license to attempt to implement the idea. My intention of writing this isn't to dissuade you from your attempt, but rather to explain my thoughts and worries regarding such an implementation. Knowing about these things in advance might even allow you to solve these problems I mentioned faster or by-pass them entirely, personally I would be thrilled if I was wrong to see a more optimized renderer come out of it.

I don't have a lot of time to do this sort of thing, and what time I do have I believe is better spent on other things.

I wish you luck with your efforts in this matter, but I felt obligated to explain my thoughts further, so it didn't seem like I was dismissing your ideas simply out of hand.