Привет, @APrinciple! На форуме действует markdown-разметка, я пару раз пытался поправить форматирование, но ты продолжаешь менять текст, так что у меня ничего не получилось.

Либо добавь форматирование (код нужно класть в три бектика (`) и название языка — в данном случае HTML), либо остановись, я сам расставлю.

Пардон, не знал, просто вносил заметку, чтобы отображает при выводе по-другому, когда два нижних подчёркивания.

Форматирование поправил.

Теперь по сути вопроса:

1. Проблема в разметке сейчас не на стороне БЭМ, а в том, что она невалидная: li лежат в nav, хотя должны быть в ul. Впрочем, добиваться валидности ради валидности не обязательно ;)
2. Следующий момент, который нужно понимать: семантика по спеке зачастую достаточно слабо связана с реальной жизнью и почти никак не связана с SEO. Семантика, которую предлагает БЭМ гораздо выразительнее и ближе к реальным задачам. Ну т.е. добавление лишних header мало что даст браузеру, поисковику или самому разработчику, а правильно подобранные БЭМ-сущности делают код надежным и читабельным сами по себе.
3. Не нужно априори бояться вложенных селекторов. Да, чем их меньше, тем CSS проще в поддержке. Но, скажем, в случае с каскадом от модификатора ничего плохого нет. Этот же пример описан в FAQ на bem.info.

По поводу header-main и header-article VS header header_main и header header_article следует руководствоваться такими размышлениями: если у разных header есть что-то общее, то это общее можно записать в .header, а отличия в соответствующие модификаторы — это позволит избавиться от копипаста. Если же они совершенно не похожи друг на друга, их действительно стоит сделать разными блоками. Но тут тогда возникает вопрос, точно ли в их названиях должно присутствовать слово header (тег header можно сохранить независимо от имени класса)?

Отдельно про исходники на сервисах Яндекса. БЭМ — это как полезные советы про то, что нужно заниматься спортом, правильно питаться и поменьше смотреть телевизор. А в реальной жизни люди зачастую ведут себя наоборот, хотя знают, что сигареты — вредно, а овсянка и бег — полезно. Вот и с сервисами Яндекса примерно такая же история ;)

1. Во втором примере -
2. Понял.
3. Я понял, но — (последний пример) 2 одинаковых <a class="header__link "> в двух разных (по модификатору) header header_main и header header_article. Как мне присваивать уникальность, могу указывать(писать) элемент, после модификатора — header_main__link и header_article__link? Или в таком случае просто каскад header_main a?

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

Как мне присваивать уникальность, могу указывать(писать) элемент, после модификатора — header_mainlink и header_articlelink?

Нет, так нельзя. @tadatuta это тоже надо в FAQ добавить.

И как тогда быть в таких случаях, например form-ы, которые в примере указываются. Их может быть 2-3. 1.

<form class="form form_login form_theme_forest">
  <input class="form__input">
  <input class="form__submit form__submit_disabled">
</form>

1. <form class="form form_ANY">
   <input class="form__input">
   <input class="form__submit form__submit_disabled">
   </form>
   

В CSS могу каскад: form_ANY .form__input {style;} Или как мне уникальность добавлять в таких случаях? Как мне правильно присвоить уникальность инпутам к form_ANY, чтобы без каскада. Я могу инпутам во 2-й форме добавить модификаторы, чтобы отличать от инпутов в 1-й форме, но как их правильно указать, чтобы понимать, что они относятся (логически связаны) именно к form_ANY? (Если не использовать каскад).

Создавать во 2-й форме 2 блока, а не блок + модификатор?

<form class="form form-ANY">
  <input class="form-ANY__input">
  <input class="form-ANY__submit form__submit_disabled">
</form>

Создавать во 2-й форме 2 блока, а не блок + модификатор?

Да, это правильный вариант. См. https://ru.bem.info/method/key-concepts/#Микс

@APrinciple не совсем правильный. form-ANY__input лучше все же заменить на form__input. Верно, @tadatuta ?

@zxqfox да, конечно

@zxqfox Приветствую! А как тогда присваивать инпутам, которые в форме form form-ANY, другие стили, которые отличаются от инпутов в другой форме? Писать каскад form-ANY .form__input? или писать инпутам во 2-й форме модификатор — form__input form__input_any? Как мне логически связывать инпуты во 2-й форме с формой, у которой класс `

Есть ли у вас работы с разметкой БЭМ? Хочу поглазеть на примеры) Спасибо за замечание.

Правильно использовать миксы:

forminput form-ANYmy-shiny-input

<form class="form form-login">
  <input class="form__input">
  <input class="form__submit form__submit_disabled">
</form>

.form__input {
  width: 100px;
}

<form class="form form-ANY">
  <input class="form__input form-ANY__input">
  <input class="form__submit form__submit_disabled form-ANY__submit">
</form>

.form-ANY__input {
  width: 500px;
  height: 50px;
}

Верно? Такой подход даёт возможность избегать повторения стилей для каждой формы, общие стили задаются классу .form, а потом миксом - добавляю нужные мне различия (изменения) добавляя класс .form-ANY__input Плюс запись короче, а по мере надобности - удлиняю, добавляя классы с дополнительными (другими) стилями. Верно понимаю, именно поэтому нельзя сразу form-ANY__input использовать?

Да. В случае использования bem-components будет не form__input, а просто input:

input form-ANY__input

form-ANY__input можно использовать и отдельно, если так надо.