Проблема была в том, что параметры создавались у прототипа, а не у инстанса.

Отправил pull request с подробными комментариями. Там три коммита: в первом обновил зависимости (это никак не связано с сутью вопроса, но не зря же мы их обновляем ;)), во втором все смысловые изменения и в третьем результат пересборки.

Предлагаю дальше подумать нам тремя направлениями для улучшения:

1. Генерировать меню с переключателями на уровне шаблонов заранее на сервере. Это будет работать быстрее и позволит не тянуть на клиент шаблоны и лишнюю JS-логику.
2. Отказаться от использования атрибутов order и необходимости заранее запоминать количество слайдов, в пользу использования модификатора current на текущем активном слайде. Тогда всегда можно будет получить его индекс в общей jQuery-коллекции слайдов.
3. Добавить JS API для удобного переключения слайдов и события при переключении, чтобы можно было синхронизировать внешние блоки с переключением слайдера.

Большое спасибо за PR с подробным разбором ошибок и недочетов.

Касательно п.1: генерация меню с помощью BEMHTML показалась вначале несложной задачей, однако я сел в лужу. Подробнее:

1. От использования list в BEMJSON отказался, решил перенести его создание в BEMHTML.
2. Пробую применять elemMatch() в шаблоне для корневого slider, чтобы подписаться на элементы item. Безуспешно.
3. Пробую просто обернуть каждый item в кастомный wrapper, чтобы опробовать applyCtx(), который наверняка понадобится на следующих шагах. Неудача.

Может, следует работать с модой default у блока slider?

Не понимаю, как реализовать задуманное. Подскажите, пожалуйста, в какую сторону копать.

Если я правильно понял, то теперь в BEMJSON ожидается такая структура:

{
    block: 'slider',
    js: {
        width: 760,
        paint: true,
        duration: 500,
        slideshow: true,
        delay: 2500
    },
    content: [
        { elem: 'item' },
        { elem: 'item' },
        { elem: 'item' }
    ]
}

А на выходе хочется

<div class="slider i-bem">
    <ul class="slider__list">
        <li class="slider__item"></li>
        <li class="slider__item"></li>
        <li class="slider__item"></li>
    </ul>
    <nav class="slider__menu">
        <div class="slider__toggle"></div>
        <div class="slider__toggle"></div>
        <div class="slider__toggle"></div>
    </nav>

?

Если так, то шаблоны будут выглядеть примерно так:

block('select')(
    js()(true),
    content()(function() {
        var items = applyNext(); // получаем значение текущей моды без учета текущего шаблона, в данном случае это равнозначно `this.ctx.content`, т.е. массив из `item`

        return [
            {
                elem: 'list',
                content: items.map(function(item) { return { elem: 'item' }; })
            },
            {
                elem: 'menu',
                content: items.map(function() { return { elem: 'toggle' }; })
            }
        ];
    }),
    elem('list').tag()('ul'),
    elem('item').tag()('li'),
    elem('menu').tag()('nav')
);

По поводу неудачных экспериментов с шаблонами предлагаю каждый отдельный момент, который вызывает вопросы, скидывать в виде ссылок на песочницу http://bem.github.io/bem-xjst/ (значения полей сохраняются в урле) с описанием, что хотелось получить в результате, тогда будет понятно, что именно не получается и можно будет внятно ответить.

А console.log() таки должен выводить сообщения в git bash в момент пересборки шаблонов (enb make / рефреш страницы при запущенном enb server).

Все верно, большое спасибо.

• Перенес создание меню и списка в BEMHTML
• Избавился полностью от атрибута order, убрал прочую лишнюю логику
• Теперь думаю насчет открытого JS API блока

Об использовании мной setTimeout() заместо setInterval(): вариант с вызовом setTimeout() позволяет убрать первоначальную (длинную) задержку до первого перелистывания при слайдшоу, которая возникает при setInterval() и отводится на генерацию события клика на первом переключателе, за что и был выбран (костыль правда). (С логированием действительно все в порядке)

А точно ли нужно эту задержку убирать? Пользователь-то должен успеть рассмотреть и первый слайд тоже ;)

В плане примера организации API можно посмотреть на порт карусели из Bootstrap на bem-core: https://github.com/tadatuta/bl-carousel/

Решил создать внешний блок remote, который при клике обращается к слайдеру.

// remote.js
modules.define(
    'remote',
    ['i-bem__dom', 'events', 'jquery', 'slider'],
    function(provide, BEMDOM, events, $) {
        provide(BEMDOM.decl(this.name, {
            onSetMod: {
                'js': {
                    'inited': function() {
                        this.bindTo('click', this._onClick);
                    }
                }
            },

            _onClick: function() {
                console.log(this.findBlockOutside({ block: 'slider' })); // возвращает null
                // пробовал также писать как this.findBlockOutside('slider')

                this.findBlockOutside({ block: 'slider' }).setMod('active', true); // модификатор для примера
                                                            // возвращает ошибку при обращении к методу null (ожидаемо)
                this.emit('slide', { current: 4 }); // данные - рыба
            }

        }))
    }
)

В слайдере, в свою очередь, следующие изменения:

// slider.js
...
'js': {
    'inited': function() {
        ...
        this.on('slide', this._onSlide)
        ...
    }
},
_onSlide: function(e, data) {
    console.log(data);
}

В консоли отладчика — null для вызова slider через findBlockOutside(), хотя структура BEMJSON следующая:

{
    block: 'content',
    content: [
        {
            block: 'slider',
            js: {
                width: 760,
                paint: true,
                duration: 0,
                slideshow: false,
                delay: 1000
            },
            content: [
                {},
                {},
                {},
                {},
                {}
            ].map(function() { return { elem: 'item'}; })
        },
        {
            block: 'remote'
        }
    ]
}

В чем дело?

findBlockOutside() поднимается строго вверх по дереву и не затрагивает сиблингов. Т.е. в данном случае чтобы «добраться» из remote до slider, нужно this.findBlockOutside('content').findBlockInside('slider'), но в целом практика обращения из блока наружу через DOM не очень хорошая, т.к. вызывает связанность блоков (например, та самая ошибка при попытке выставить модификатор, если слайдера рядом не оказалось).

Подробнее про принципы взаимодействия блоков в JS см. https://ru.bem.info/forum/163/

Пробую к remote примешать блок slider.

{
    block: 'slider',
    ...
},
{
    block: 'remote',
    mix: { block: 'slider' }
}

// slider.js
    // в конструкторе
    this.findBlockOn('remote').on('click', this._onRemoteClick, this); // возвращает null

// remote.js
modules.define(
    'remote',
    ['i-bem__dom', 'events', 'jquery'],
    function(provide, BEMDOM, events, $) {
        provide(BEMDOM.decl(this.name, {
            onSetMod: {
                'js': {
                    'inited': function() {
                        this.bindTo('click', this._onClick);
                    }
                }
            },

            _onClick: function() {
                this.emit('click');
            }
        }))
    }
)

Связь через this.findBlockOn() идет только в том случае, если структура BEMJSON такова:

{
    block: 'slider',
    js: { id: 'together', ... },
    ...
},
{
    block: 'slider',
    js: { id: 'together' },
    mix: { block: 'remote' }
}

Судя по всему, это и есть способ расположения одного js-блока на несколько DOM-узлов. Вопрос: это нормально, так и должно быть? (Почему remote не ожидается как блок-микс со специальной декларацией? Ссылка ) Хорошая ли это практика для связи внешних (удаленных) переключателей?

Дополнительно: как в таком случае быть с методом updateWidth(), который теперь применяет новые стили как для "корневого" slider, так и для его "переключателя" (там это явно лишнее)? Пока только сильно привязанный к контексту хак: this.domElem.eq(0).css('width', width);

Да, один блок на нескольких DOM-узлах требует совпадающего id в js-параметрах. Это необходимо, т.к. на странице может быть несколько разных слайдеров, каждый со своим собственным remote, нужно как-то отличать, какой чей. Подробнее про эту связь см. https://ru.bem.info/technology/i-bem/v2/i-bem-js-html-binding/#Один-js-блок-на-нескольких-html-элементах

Блоки-миксы — это другая история. Они исключительно о том, чтобы добавить их функциональность другим блокам. Например, есть некоторый метод doSomething(), который необходим блоку b1 и блоку b2, при этом b1 и b2 совершенно разные. Чтобы не копипастить логику про doSomething(), ее можно вынести в отдельный блок-микс и примиксовать к каждому. На этом смысл их существования исчерпывается.

Дополнительно: как в таком случае быть с методом updateWidth(), который теперь применяет новые стили как для "корневого" slider, так и для его "переключателя" (там это явно лишнее)?

В данном случае можно просто задавать ширину для slider__list. В общем случае, при использовании подхода с разнесением блока на несколько DOM-узлов, можно добавлять некоторый специальный элемент (inner, main, etc).

Ну и остаются еще варианты: организовать взаимодействие через общего родителя, который подпишется на события от remote и вызовет метод на slider, либо применить глобальный канал событий / модель, храняющую общий стейт и т.п.