We need a way of allowing plugins written in scripting languages like Perl or Python. These could interface with other programs, perform various changes on the molecules, etc.
Suggestions for an "All Atoms" API:
GetCurrentCRD()
SetCurrentCRD()
AddAtom()
AddBond()
DeleteAtom()
DeleteBond()
...
This probably also needs some sort of "global hook" for putting in a menu item and then calling main() for the plugin.

Ideally, the engine should allow exporting the graphics--e.g. create an offscreen buffer that's potentially larger than the screen and then save it to a file.
This would allow high-res JPEG or PNG files for presentations.

Yep. At least the MESA opengl variant supports off-screen rendering directly.
Then we have had that idea of coverting the current view to commands for a ray-tracing program; a nice idea but I guess I don't have time for that very soon.... :(

This is a bit complicated, but it would be fantastic to have an undo/redo feature to undo the last action. (This is especially a big deal if the geometry optimization screws up.)
I don't know a good way of dealing with this--though an easy (but memory intensive) solution would be to keep a copy of the current coordinate set and camera as the "undo" buffer.

Here's an idea for the "library" feature.
Have a user-definable folder for the library--default to the same path as the parameters, etc. The user could set this in the prefs.
The library/ directory could have one level of directories, then a bunch of Ghemical files. So a menu could contain items for each of the directories and these would list the files. Choosing a file would Open/Insert it into the current project.
This allows the user to easily file and modify items in the library. (And it's not too hard to code.)

Yep.
We haven't really specified a file format for QM files, but it looks like the MM file format would be just fine.
There we have those !Sections, and for QM models we might have some different !Sections present,
but we can always ignore those !Sections that we don't need...

I think we could even compute the vibrations ourselves... For all models, we can calculate the 1st derivatives, and using those I think we could calculate 2nd derivatives numerically. Then from 2nd derivatives it is possible to solve the vibrations somehow... I guess :)
Anyways, when we have the displacement vectors, it would be very easy to animate them!

For measuring, it's sometimes useful to define a temporary dummy atom as a centroid. (Either cartesian or mass-weighted)
This would obviously not necessarily be updated by other actions, but at the least it would make some measurements easier.

Some tools to set bond lengths, angles, torsions, etc. to particular values would be helpful.
Along the same line, it might be helpful sometimes to have "alignment" tools to set the position to a particular X, Y, Z, etc. (Yes, you can edit the file, but it's sometimes nice to do this in the editor.)

I think this actually works, in a way... :)
You see, you have to use in "erase" exactly same logic as in "draw" when you add a bond. So, erasing is an "un-adding" operation: to remove a bond, press MB down at 1st atom, move mouse to 2nd atom, and release MB.
The reason why it works this way is, that the OpenGL selection code can detect only atoms, and no bonds. So we just select the atoms, and later figure out what bond the user meant.

This sounds like something that should be added to the OpenGL selection code, at least for the erase tool. Granted, you're correct that this works, but it seems more intuitive to click on the middle of a bond to see it disappear.

Currently the file import doesn't attempt to determine double bonds, etc. This would be useful.
Beyond that, the same code might be useful for "retyping" after a QM calculation or in a trajectory--recognizing aromatics, etc.

Yes, it's certainly a nice idea to add it to the base OpenBabel library. However, the code is not strictly under the GPL--but the author gave me an OK to include it in Ghemical.
I'm not sure how he would feel about including it in a library where the source is more exposed. But I'll contact him about it. Obviously it would be nice to put in symmetry elements for filetypes that support it.
-Geoff