Re API, I think it could be quite useful when you want to manage several PCs remotely. I currently use a combination of proxy (to switch pools), scripts (to restart the miner with # of threads = 50% of cores when someone is going to use that computer) and manual log review to monitor the status. An API that could let you check the status, switch pools and # of threads would be ideal for that.
I think the main problem with adding an API is that it would greatly complicate the code base. Luckily cpuminer starts up very quickly, so a wrapper script can usually do the job pretty well.
Re logging I'm using the 2 >> logfile.log (Windows) at the end of the line to log to a file. This creates the log file but does not output anything to screen.
That's what
tee is for. Or you could
tail -f the file where the output is stored.
Also a --sharelog option allows you to output the accepted shares on a different file for easier reviewing.
This could indeed be useful. I will think about it, but keep in mind that the changes required to implement this properly are nontrivial (cpuminer does not currently keep track of submitted shares).
By dynamic screen I didn't mean a GUI. I'm not sure if you can call what the other miners have a "graphical interface", but I was thinking more like the options to manage pools and processors without having to restart the miner with different parameters. An API could solve this issues too.
Personally, I think cpuminer was never designed to be interactive... and I actually like it the way it is, because I value simplicity. But then again, this is probably a matter of personal taste, just like the old vi-vs-Emacs debate.
(By the way, I just learned that there's a name for the kind of user interface that cgminer sports:
TUI, i.e. Textual User Interface.)