Thanks for your prompt and valuable feedback guys. Some comments follow (I'm sorry for large text, but you produced a lot of good comments I wanna react to):
Collision boxes: a source of never ending troubles when wanted to be perfect and precise with irregular and dynamic shapes. If tried to use Rect2D_OBB with CollisionOffset, rotation of model did not update collision bound box properly. I would expect that by rotation of a model also CollisionOffset is rotated, which is not unfortunately the case. Instead of updating it "manually" by each rotation I used Circle2D for all larger objects, which is simpler but not precise of course. Another problem was collision bounds of irregular asteroids. Size is given by original sphere but the shape noise is not taken into account. Therefore, sometimes collision is outside and sometimes inside the actual shape of asteroid. Used collision bounds are always trade-offs.
Difficulty of playing: I was playing asteroids-style games from my childhood - that's why I did not realized difficulty of playing by other people. But I'm sure after 10+ minutes player can get some skills and can have more fun. A small trick: you must be far enough or thrusting back when shooting "bursting badguys"
(I call them mines). I thought that's the only difficult thing in the game (instead of a lot of flying objects in levels up to 9), that's why used this density of generated bullets.
Sound on/off: that's good idea that muting will just decrease level of all sounds but music is switched off. Do I understand it correctly jph?
Key repeat buffer fill limit problem: there is no a key repeat buffer fill limit, the behavior is intentional. If you look at top of the screen, there is an energy (gun overheating) bar marked by battery symbol. If you do not have energy, you cannot shoot. To help player, energy is slowly charging automatically by time. A consequence is that if you do not have energy to shoot a single bullet, after some time you can shoot again, but the frequency is smaller that the normal one. One possible change would be that frequency of shooting is proportional to energy; what do you think?
Battery charging: As you surely observed there is a "large" battery flying around from time to time. Its catching charges the whole energy bar. But I like the idea of small batteries appearing at places of destroyed enemies; thanks for idea jph!
Music: As Kjell mentioned I used Music component to load midi file and MusicControl to switch on/off the background music. I had several quite successful experiments with producing realistic sampled instruments if midi contains more than one instrument (tested on Metallica, Dream Theater and Pink Floyd), but the current version of ZGE has some usability restrictions (e.g. do not import also instrument sounds, or editor of sound component is not synchronized with sound's properties and it's settings are not properly saved) and the final exe is much larger, because of imported samples (raw files) for each instrument. Finally, I decided for very simple one-instrument midi and sound created by built-in sound synthesizer. Laugh was imported as a raw file generated in OpenMPT (the laugh sample was taken from some public sound library). I was also trying to use bass library to play MOD files and later also mp3 files, but distributing more than one file is not what I wanted to do with such a simple game. Which editor do you use to produce/transform MOD and raw files? I used OpenMPT, but I'm not experienced in this area. BTW online help mentions Audacity as possible producer converter to raw files. I was never able to produce a correct raw file with Audacity.
Performance: FPS-text is rendered/updated on each application's OnRender pass with the current value. I will check my meshes to find opportunities for reduction of point numbers. One problem I see is explosion of rocket decreasing FPS twice. I used two RenderParticles, both with 100 ParticlesPerSecond. Isn't it too much? Another problem might be rotating of stars. I used dynamic rotation of textures made of 128x128 bitmaps. Should I use some another technique, e.g., sprites or particles instead of bitmaps?
Problems with texture mapping: a general problem I was not able to cope with was to apply textures on spheres seamlessly. After some experiments I finally used Generated TexCoords, because it's simpler, but is not looking nice as you can see it on asteroids. I also tried to compute TexCoords for sphere-based meshes and to apply ModelDefined mapping, but I always had problem with one segment (meridian) of sphere where the mapping was corrupted. I also tried to use GLSL shader to map texture, but with the same problem (even if the shader was correct in ShaderDesigner). The reason is probably incorrect (discontinuous) mesh for sphere. Can someone give me an example of seamless mapping of a texture to sphere?
Sources of learning: included help file (nicely done!), this forum with many submitted examples, video tutorials on YouTube, and Wikipedia for info about sound generators.