1) That is the formula I'm using, but after looking into the code, I found that the enemy velocity was incorrectly multiplied by the deltatime. Since I usually test the game at ~1000 FPS, this threw off the accuracy greatly, so during the initial gamejam, instead of attempting to fix it, I just "compensated" by subtracting 0.2 from the predicted bullet speed. Removing the delta and compensation has fixed the prediction.
3) I'll see if I can get a hybrid approach: use variable timestep, but if the FPS falls below a threshold (15), I prevent the used delta-time from getting any higher. So, game slowdown would only occur under 15 FPS, which is (hopefully) above the FPS where things start to glitch through walls.
4) Uhhh, looks like I broke the junction with a recent update. In fact, when I tried to use one, my game crashed. Just fixed it.
7) I'll see if I can disable the deselection and display some sort of error when you place something without sufficient resources instead.
I'm using libGDX, a Java game library, as the framework. I have Mindustry on GitHub, here.
(note: I'm also using a custom library, uCore, which provides utilities for and wraps a lot of libGDX classes, so big chunks of the code won't resemble standard libGDX)