If it keeps you generating feedback like that, be as mean as you like! I need stuff like this.
The source file thing is definitely strange. I could just lose it entirely; save your own files! That's how the termbox client works. It made slightly more sense when it was driven from the CLI.
"compile" in the debugger is vestigial, but if we think it makes sense to have it do something useful, let's have it do something useful. I'll have it do what the compile button does, and also print a summary of the generated program. It'll be immediately clear what it does. I'll make "load" do something sensible too.
I think more people want me to have a command line than want a completely streamlined interface, but I think I have some work to do on making the command line work better.
There is utility, later on, in looking more carefully at the individual steps of getting a program to run, but there is not much utility to it in earlier levels. I can hide those commands earlier; I didn't because that'd be kind of a tell. Earlier on this year, I wanted this interface to capture more of the annoyance of figuring out a realistically complicated target (rather than it being immediately clear what your objective was), but I'm moving away from that now.
It's definitely very tricky to write documentation for this that makes sense to reversers or embedded devs and that works for the people who've never done any of this kind of stuff. Maybe I shouldn't be trying to accomplish both things in one set of documents!
My #1 takeaway from your original comment: I need to do an audit of all the command line commands and have them all be discoverable by running them and seeing what happens. That is definitely not the case right now, and it's a very easy gap for me to close.
There shouldn't really be anything you can do in the web interface that you can't do in the API.