Hi! Thanks so much for the detailed feedback 
Some aspects of the fully manual image mode are still experimental and the current feature set mostly focuses on fast annotation for common computer vision tasks (where high-res images and high-precision annotation are also a lot less important).
The auto-adjusting line thickness and font size also came up recently in this thread – I definitely want to update the algorithm here. We could then easily have a "base size" setting that lets you adjust the general line width (the visual "target size" of the lines etc. after the image was auto-resized). Exposing other config settings shouldn't be a problem either – we didn't expose everything yet because I wasn't sure what people would actually need. But in general, pretty much any semi-hardcoded size can be exposed as a config setting, if needed.
The image width adjusts to the width of the card, so you can overwrite the "cardMaxWidth" value in the "customTheme" settings in your prodigy.json or recipe config to fit more of the image on the screen.
When you're taking about zooming in your use case, I assume you mean really zooming in and enlarging the image, even beyond the default screen width, right?
For cases like this, it might make sense to add some kind of image-only zoom functionality to the image container instead of "hijacking" the native zoom. Maybe something similar to Google Maps zoom? (I'd have to read up on this and see what the implications are and what makes the most sense for Prodigy.)
Native browser zoom is supposed to increase the size of everything proportionally – including text, buttons and other elements. Changing that behaviour would produce very counterintuitive results and potentially be very problematic for accessibility.
For full flexibility, you can always edit the static/index.html and put in any CSS or JS. The current view_id isn't easily exposed at the moment – it's a good point thought, and I'll definitely add this to the JS support (currently experimental and available for testing in the HTML view).
As a quick and dirty workaround, you could add a query variable to the web url, e.g. localhost:8080?choice and then check for that via the window.location.search. If it's "choice", your script could then append a <style> tag to the <head> which hides the buttons via their CSS class (I don't think it currently has a human-readable one, but the class will be consistent throughout the app).
Features like masking are probably a bit out of scope at this point. For the objects that are this complex, maybe you'd actually be better off using a real graphics program or illustration tool instead? Those tools really focus on what you need, and you'd still be able to automate a lot of the process before and after.