неоднозначный оператор [] в вариативном шаблоне

Портативный способ сделать то, что вы хотите, примерно:

template<class...Ts>
struct operator_index_inherit {};
template<class T0, class T1, class...Ts>
struct operator_index_inherit<T0, T1, Ts...>:
  T0, operator_index_inherit<T1, Ts...>
{
  using T0::operator[];
  using operator_index_inherit<T1, Ts...>::operator[];
};
template<class T0>
struct operator_index_inherit<T0>:
  T0
{
  using T0::operator[];
};

тогда:

template<class... Fields>
struct ctmap : operator_index_inherit<Field<Fields>...> {
  using base = operator_index_inherit<Field<Fields>...>;
  using base::operator[];
};

здесь мы линейно наследуем от каждого из типов и using operator[] от наших родителей.

Если бы мы могли using Field<Fields>::operator[]...;, нам не пришлось бы этого делать.

С конструкторами нужно быть осторожным (чего я не делал), но вам может и не понадобиться этого делать.

живой пример.

То, что на самом деле идет не так, зависит от деталей стандарта, в которых я менее чем уверен. По сути, вы смешиваете операторы, наследование и перегружаете сложным образом. Даже если ваш код соответствует стандарту (что может быть, а может и не быть), он соответствует требованиям, от которых умирают некоторые компиляторы.

Код недействителен, и gcc правильно отклоняет его (хотя clang 3.6.0 его принимает - это ошибка). Правила поиска оператора начинаются с [over.match.oper]:

[...] для бинарного оператора @ с левым операндом типа, чья cv-неквалифицированная версия равна T1, и правым операндом типа, чья cv-неквалифицированная версия равна T2, три набора функций-кандидатов, обозначенных member кандидаты, кандидаты, не являющиеся членами и встроенные кандидаты, строятся следующим образом:
— если T1 является полным типом класса или классом, будучи определенным, набор кандидатов в члены является результатом квалифицированного поиска T1::operator@ (13.3.1.1.1); в противном случае набор кандидатов в члены пуст.

Правила поиска для имени члена (поскольку мы ищем ctmap<last_name,age>::operator[]) из [class.member.lookup]:

Набор поиска для f в C, называемый S(f,C), [...] вычисляется следующим образом:

Если C содержит объявление имени f, [...]

В противном случае (т.е. C не содержит объявления f или результирующий набор объявлений пуст), S(f,C) изначально пуст. Если у C есть базовые классы, вычислить набор поиска для f в каждом подобъекте прямого базового класса Bi и объединить каждый такой набор поиска S(f,B_i) в свою очередь с S(f,C).

Следующие шаги определяют результат слияния набора поиска S(f,B_i) с промежуточным набором S(f,C):
— [...]
— В противном случае, если наборы объявлений S(f,B_i) и S(f,C) различаются, слияние неоднозначно: новый S(f,C) является набором поиска с недопустимым набором объявлений и объединение множеств подобъектов. При последующих слияниях недопустимый набор объявлений считается отличным от любого другого.
— [...]

По сути, у нас есть два базовых класса, оба с расширением operator[]. Оба набора объявлений различаются, поэтому слияние неоднозначно. Чтобы устранить неоднозначность, можно было бы ввести using-declaration, включающие все функции-члены базового класса в производный класс, чтобы начальный поисковый набор находил все.

Чтобы сократить ваш пример:

struct A { void foo(char) { } };
struct B { void foo(int ) { } };

struct C : A, B { };

struct D : A, B {
    using A::foo;
    using B::foo;
};

С этой иерархией

C c;
c.foo(4);  // error: ambiguous lookup set for foo()

D d;
d.foo('x') // OK: calls A::foo()