И там, и там - "тело". Если это сложно осознать, могу лишь предложить дальше читать о JS, в частности, стандарт.

Вы слово "создание" заметили? В Вашем примере тело уже статично создано выше программистом, написавшим код тела, в моем примере - программа создает это тело в зависимости от внешних для программы условий. Есть разница?

var A = function (a, b) {
  this['ТоЧтоВышеВвелПользователь']; // если, конечно, у Вас есть такое свойство/метод
  return a + b;
};

Сути это не меняет, в обоих случаях - динамические функции (FE), создаваемые в рантайме (только в случае с new Function еще и [[scope]] будет только глобальный).

'Function' парсит/eval-ит аргумент, создавая тело и проч., если именно эта eval-ная динамика подразумевается (новый агрумент -> новое тело -> новая функция), то в этом смысле обычная прописанная FE - вариант статичный.

Zeroglif, ну да (хотя, тело можно и проeval-ить).

Возник вопрос :
Интересно, в Javascript реализуется корректно множественное наследование ? Где-то можно увидеть описание, желательно понятным языком ?

А оно как-то реализуется, чтобы спрашивать про корректность ? ;)

Хороший ответ. Я сам-то вначале задал вопрос, а потом подумал о таком возможном ответе. Я могу сказать, что - не знаю. Но :
1) Хотел бы узнать, как это сделано в C++, поскольку тоже не знаю, как там, но термин оттуда слышал.
2) Хотелось бы услышать , как кто себе это представляет .

Если говорить о SELF-e, откуда JS зачерпнул свои прототипы, то там: "SELF’s inheritance system supports multiple inheritance by allowing an object to have more than one parent." В JS один или "more than one"? Один.

"Примеси" (обычным расширением). Но физически это, всё-же, расширение, а не ссылки на объект-"примесь" (как, например, в Ruby). Примеси позиционируются как альтернатива множественному наследованию.

В Java, альтернатива - интерфейсы, реализация которых, - есть полное описание (имплементация) методов этих интерфейсов; в JS того же можно добиться обычным написанием этих методов (или "подмешиванием").

update:

Если "js-кроссдвижковость" не столь важна (а именно - код пишется под Mozilla'вцев, Spider Monkey), то можно подключить механизм с __noSuchMethod__, в котором устроить нужную диспетчеризацию по дополнительным родителям (в __noSuchMethod__ управление передастся, когда вся цепь прототипов будет просмотрена, и нужный метод не будет найден).