Avoiding verbose compositional class design

Question

*"...so how is one supposed to avoid all the duplicated methods in choosing composition over inheritance?"

I assume you are talking about JavaScript.

It might be a minor point but In JS we use functions, methods are reserved for the engine where the name comes from the language it is written in V8 for example is written in C++

Duplicating functions

There is no need to duplicate functions no matter how you create your object in JavaScript.

I just can not workout why you would want to do

From your bottom snippet

mthTen() {                // WHY??????
    this.math.mthTen()
}

Examining your example via rewrites

Defining the objects

const Events = () => ({evOne() {}, evTwo() {}});
const Maths = () => ({mthOne() {}, mthTwo() {}});

BTW Use literal if you don't need closure

BTW you would only define objects (using this pattern) via functions if you were closing over some encapsulated data. They are better defined as literals in this case, avoiding the creation of unused closure for each object

const events = {evOne() {}, evTwo() {}};
const maths = {mthOne() {}, mthTwo() {}};

At the object level

If you want the functions to be accessible at the object level you may build it as follow

const createFoo = (math, events) => ({...math, ...events});
const obj = createFoo(math, events);

// Calling
obj.evOne();
obj.mthOne();

At the object property level

To create them as named properties

const createFoo = (math, events) => ({math:{...math}, events:{...events}});
const obj = createFoo(math, events);

// Calling
obj.events.evOne();
obj.math.mthOne();

As static functions

In many cases you would use them as static functions.

// static instance reference. There is only one math and events for many Foos
const Foo = (math, events) => ({math, events});
const obj = Foo(math, events);

// Calling
obj.events.evOne();
obj.math.mthOne();

Or // Static instance. There is only one instance of math and events referenced by the constructor Foo const Foo = Object.assign(() => ({}), {math, events}); const obj = Foo();

// Note access via the instantiation function  Foo
Foo.events.evOne();
Foo.math.mthOne();
obj.event.evOne(); // will throw as it does not exist.

Or

// Static instance functions. There is only one instance of math and events 
// referenced via functions of the constructor  Foo
const Foo = Object.assign(() => ({}), {...math, ...events});
const obj = Foo();

// Note access via the instantiation function  Foo
Foo.evOne();
Foo.mthOne();
obj.evOne(); // will throw as it does not exist.

Note there is no formal way to define static functions its only static by how it is used and instanced (Via the class syntax static is just syntactical sugar for (assign to constructor, rather than prototype))

If you must duplicate

Warning Don't do this at home, it is only as an example. Doing this in any code can result in severe confusion and eventual application death.

If you really wanted to have a second copy of each function. eg obj.evOne and obj.event.evOne You can automate the function creation, binding the copied function references to the object you want as this

const events = {evOne() {}, evTwo() {}};
const logger = {
    logA() { console.log("A" + this.count++)},
    logB() { console.log("B" + this.count++)}, 
    count: 0
};

const addFunctions = (obj, ...instances) => {
    for (const instance of instances) {
        for (const [name, func] of Object.entries(instance)) {
            func instanceof Function  && (obj[name] = func.bind(instance));
        }
    }
    return obj;
}

const createFoo = (a, b) => addFunctions({logger: a, events: b}, a, b);
const foo = createFoo({...logger}, {...events});

foo.logger.logA();  // should be A0
foo.logA();         // should be A1
foo.logger.logB();  // should be B2
foo.logB();         // should be B3

Question

"What would the draw backs be compared the style of composition where each class you compose with is given a field name (I'm calling this named composition)?"

This question is way too subjective to answer in any death.

There are drawbacks to every pattern, how the drawbacks effect the code quality is very dependent on the coders skill and level of experience.

If you are comfortable with a pattern and have the experience your proficiency outweighs any pattern's drawbacks.

The biggest drawback to any pattern is how experience a coder is in using it.

To be a well rounded coder you must gain proficiency in all the patterns.