.hero { 
    z-index: 10; 
}
.main-tabs { 
    z-index: 11;
}

.hero .drop-search {
    z-index: 12;
}

Для класса main-tabs класс drop-search имеет z-index родителя. Указанный для класса .drop-search z-index актуален лишь внутри hero
Надеюсь, правильно написал

Да, я понимаю какие правила работы у з-индекса

Но такая ситуация встречается не первый раз, просто интересно как опытные верстальщики её решают, может есть какой-то обход) вывод объекта в другой контекст с помощью js без потери позиционирования

Дизайнеры задают задачки)

Ну она не должна возникать проблема-то, камон. Кроме шуток.

В худшем случае — popper, да.

Значит со структурой элементов интерфейса что-то не то

Ну как не то) Дизайн заставляет)

а зачем z-index на кнопках-то?

Дели иначе

которые поиск по отрасли, бренды и тд

Фон отдельно, хедер отдельно

Я не вижу тут проблемы

Они относятся к нижнему конфигуратору, там 3 таба с контентом во второй секции.
Они накладываются на верхнюю секцию по дизайну (фон прозрачный)
Подключен плагин переключения табов, который работает с контентом второй секции, по среднему табу вообще конфигуратор всплывает
В первой (верхней секции) уже готов слайдер (крутится)

И всё вобщем-то уже работает, как вдруг возникает вот такое пересечение)
Понятно что можно переписать много чего, и решить в итоге проблему, но спросил у кого может есть другие наработки)

Я не понимаю, почему ты не принимаешь ответ “сделать иначе” как наработку.

Всё остальное — как раз костыли.

Да, можно и так, но уже всё свёрстано под мобильную версию

Прописано куча медиазапросов, которые основаны на данной структуре

.item-svg: display none; &:hover: display: block;

Благодарю. А в целом это вообще адекватное решение, чтобы сделать например такой эффект