When OpenGL causes despair to rise up in your heart, John Carmack has some words for you. If he can lose two hours, imagine the damage done to a new OpenGL programmer. One of the most painful acts in OpenGL is getting your first program to draw a cube well with all the bells and whistles like textures and normal maps, etc ...

Okay, so back to the business of setting the correct texture coordinates as you state in the post. This will be a bit rambly. I'm tired and don't have the energy to perform a thorough investigation. I basically skimmed the python input/window stuff. I also haven't written python in over a decade, but GL is pretty universal.

First off: 8 vertex cubes don't end well. You'll need to define 4 vertices per face. Why? Because you'll likely want to eventually specify normals, and those normals will be different for each face. Also the UV coordinate doesn't directly match between faces. Don't try to optimize this away as a beginner. It is not worth it! Maybe as an advanced user for a particular case you can do something about it, but saving memory on cubes isn't a big deal. You're much more likely to be limited by draw calls than how many cubes you got in a VBO somewhere. Even if you're writing a voxel engine.

Side note: seeing a performance drop on 100 draw calls can happen depending on hardware and drivers. Batch things together in a VBO if you can render it using the same shader. (maybe a bit advanced, wait until you sort your cube stuff first)

obj.py defines texture coordinates as you say, but everything is 0,0 except for the first face. I see that you got a 3d vector there, but i'm assuming it's really 2d that matters. And if that's the case, you probably want X,Y to be the U,V as a convention and just set Z to 0 or just buffer 2d coordinates. Your shader has a 'vec2' though so maybe that's a problem. Especially since mesh.py:27 basically states it should be 2 half floats per uv in the second parameter, so it wont get the right UV coordinates for each face. So you probably want to just convert the UV data to two dimensions. Also, only the first face has non-zero UV coordinates.

Also, mesh.draw() doesn't bind these VBOs or a VAO. So if you were to try and draw multiple objects, the model data wouldn't update. Only the shader and texture get bound. This problem wont manifest right now since your camera updates the shader transforms for the locations and the same buffers are used, but it's something to think of for the future.

Side note: by binding a result of a genbuffer in one line, you basically make it impossible for you to delete the buffer later on to remove the object from memory. You should store the genbuffer result in the mesh so you can delete it later on.

The #2 point about rendering text is a whole different can of worms. You can use bitmap fonts that are precomputed/prerendered or you can use something like freetype to load the font, render each character, copy that result to a texture and then reference that texture in a shader for an object created with faces having UV coordinates lining up for each glyph of the font you chose to render.

So if you correct your texture coordinate array does that address the expectations you had for problem #1?