Probably 
At least, we always try to advocate for simplicity and reframing the annotation tasks, rather than rebuilding "traditional" annotation workflows with Prodigy. But of course, this always depends on the use cases, and there can always be exceptions from the rule.
In general, the Prodigy web app will determine the interface to use based on the view_id and will then stick to that. However, some interfaces support rendering different types of content – for instance, the classification interface can render text, text with entities and images. So if your stream contains different task types, Prodigy will "switch" between the different types of presentations (but within the same parent interface). Similarly, choice tasks and their options can be text, text with spans or images. So maybe there's a solution you can come up with that takes advantage of this.
Not at the moment, no. (As a general rule of thumb, if your options are too long for the list, you might also want to consider simplifying your task.) As a workaround, the ner_manual interface supports a dropdown instead of a list of buttons, though – but in order to "lock in" the label, you'd have to select some text, so I'm not sure how useful this will be.
Alternatively, since a dropdown is a pretty standard HTML element, you could easily build something yourself using a HTML template and the new custom JS option. However, this is still experimental and currently undocumented in Prodigy v1.4.x (aside from on the thread), so usage is at your own risk.