You idea with buttons is great as it allow more freedom to the users

It is also targets another issue - constant need to tell the ordinary (not from IT faculty) teachers why their choices dislpayed 'incorrectly'.
The standart Moodle way is: what is entered in line edit will be displayed as it is. So I think that 'normal' - line edit - choices must be displayed as text, and if the user want html - he/she can use htmleditor.

There are two questions with this:
1) using buttons I think there is a point in chagning default behavour: buttons must befault to not use htmleditor to speed up loading of the first page
2) choices can be entered as text of html, but we need to save them in db in one format. I think that this will be html, with conversions done to plain text.

And the state of the buttons should be stored as user preferences, so Moodle remembers how each user has it from one session to the next (the show/hide advanced buttons do this).

The browser pausing quite much while loading page, and the pause is proportional to the number of HTMLEditors on it. Pressing button to off it not helping at all - it's what's loading on the page that matters. So it should be solved server-side.

However, control for using HTMLEditors in repeated parts must not necessary be part of the question editing screen, if you really don't want it there. It can well be part of question configuration, or even user profile. I can accept any you suggestion on that matter.

Before I give up, I have one remaining hope: Apparently there is an option for TinyMCE, so only one instance gets initialised on the page, and then whichever field you edit uses that instance. (It moves and attaches itself to the current text area.)

I saw that in a forum once, but I can't find it again now.

Anyway, before trying anything else, I would like to see how well that option works.

I browsed TinyMCE docs, and found no such option, but some other things to consider:
1) using tinyMCE compressor is recomended to speed up dowloading, but Moodle doesn't seems to use it now (maybe there is a reasons why, but I don't know them)
2) there is an 'ask' option, which converts textareas in TinyMCE instances asking users if they want to do so when they first focus textareas- but this may as well be annoying to the user
3) there is a mode, in which only some classes of textarea get converted (i.e. editor_selector), but docs say nothing about is this working with dinamically changing classes after the page was loaded, and so it probably not
4) instances can be added/removed dynamically by custom scripts using tinyMCE.execCommand with mceAddControl/mceRemoveControl

Is anything of this of particular interest to you?
There is also this forum post, http://tinymce.moxiecode.com/punbb/viewtopic.php?pid=22977, but it address more a problems of AJAX editing where areas may be added/deleted dynamically, which is not the case.

$mform->addElement('htmleditor', 'correctfeedback', get_string('correctfeedback', 'qtype_multichoice'),
array('course' => $this->coursefilesid));
$mform->setType('correctfeedback', PARAM_RAW);

$mform->addElement('htmleditor', 'partiallycorrectfeedback', get_string('partiallycorrectfeedback', 'qtype_multichoice'),
array('course' => $this->coursefilesid));
$mform->setType('partiallycorrectfeedback', PARAM_RAW);

$mform->addElement('htmleditor', 'incorrectfeedback', get_string('incorrectfeedback', 'qtype_multichoice'),
array('course' => $this->coursefilesid));
$mform->setType('incorrectfeedback', PARAM_RAW);

on multichoice form to foreach by array('correctfeedback', 'partiallycorrectfeedback', 'incorrectfeedback')? That would lessen things to modify for both main (that may be eventually) and local modifications. I'll write a patch if it's OK.

Neither of the browser was crashed (or reverted to textarea, as it was in case of too many HTMLEditor instances), which is a good news. It may mean that such strategy may work well: convert desired textarea in TinyMCE instance only when user focuses it (initiating one instance is sufficiently fast). Too many instances by itself is not that problem if there is enough RAM (which usually is).

There are two ways to implement this:
1) easy but somewhat annoying: use "ask" mode of TinyMCE on pages with 5 (number is debatable) or more instances
2) get all fields textarea at first and initialise them later by tinyMCE.execCommand with mceAddControl when user focuses it

That way thefields user don't want to touch will never be initialised, which is generally good, but may be somewhat inconvenient if user want just see a text on some fields - he must focus on it to see it correctly (and may be confused with html if he not a programmer, we must remember not all people are).