Структура интернет-магазина

Хм. ни когда не сталкивался с такой необходимостью. Т.е варианта точнее два. Как я понимаю, это некие два товара раличющиеся какой то характеристикой?

Из моей практики (самый привычный пример размеры обуви/одежды) либо они так и имели один и тот же URL и различие только в get параметре. (Хотя тут, кстати, ID подставлялся). Либо (сильно реже) делали в подобоных случаях разные страницы и в урл отражалась отличающаяся характеристика (конкретно с размерами не припомню чтоб встречалось, но уж коль я начал 

этот пример) man-slippers-s43

тут к ИД привязка, на мой взгляд "опасна", предположим  первоисточником является внешняя система (например 1с). Вот прилетает товар из нее и создается ИД, а значит "фиксируется" какой то урл. Далее по каким то стечениям обстоятельств (тут предлагаю не углубляться "почему так случилось") это товар удаляется. И потом вновь прилетает из 1с. С точки зрения сайта, 1с-ки, - ну ни чего особо критического не случилось. Товары связаны по GUID.. Но вот URL сменился. А ради чего?

Но бывает. Например, два визуально и технологически идентичных товара. Разница - производитель и цена. 

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

Часто бывает в какой-нибудь метизной продукции.

Я сталкивался и не раз.

Как сказал выше, могут быть два абсолютно одинаковых товара.

А бывает вообще один и тот же товар, но в зависимости от поставщика и времени закупки цена другая.  

В общем бывает много занятные случаев, поэтому id снимает проблему.

На мп много одинаковых, на им конечно редкость когда нельзя уникализировать название и соответственно урл. 

В корне не согласен. Для этого есть теги/аттрибуты во всех популярных CMS и фреймворках. Если говорить про утекшую инфорамцию давно, а новой всё ещё не было, даже ЧПУ прогоняется по аналогу bm25. И лишние вхождения плодить смысла нет.

Да им плевать - они все равно всегда в топе

именно. И лучше уж тогда использовать классификатор товаров по госту или я не знаю как это счас в россиях называется. Айдишка - слишком непостоянная вещь, я бы на такое не ориентировался. Брать из 1С например

Конечно, не понял. В огромных каталогах возможны дубли. И в старых версиях. Поэтому добавляют ID из того же 1С или артикул, которые стабильно и всегда уникальны. А вот формировать листинг по чпу - это всё таки жрать ресурсы. )

И вторая часть. Это если ты делаешь вариантивные товары (1 URL - без изменения ссылки / добавление хэша / т.д.), но если у тебя описание меняется, товар конкурентный, то делаешь под каждый товар отдельный URL. Простой пример - iphone. У тебя на каждую модификацию по хорошему уник описание и свой URL, чтобы закрыть ассортиментный ряд. Но если параметр изменился небольшой, о котором ты и думать не думал, то будет дубль. Если утрировать, была камера 16 на 4, стала - 24 на 6 в новой про плюс супер модели. А у тебя этого префикса в предыдущем ЧПУ не было. 

В CMS-ках и фреймворках много чего есть, но когда ты имеешь дело просто с набором URL-ов, то именно из списка URL-ов тебе необходимо выполнять выборки.

Здесь верно, только "не прогоняется", а рассчитываются.

Лишнего здесь ничего нет.

В чём твой корень несогласия? В том, чтобы в товарном алиасе вместо транслитерации названия и ID был просто ID?

Что значит непостоянная? Выполнили импорт из 1C, конкретному товару назначился ID, дальше он указывает на уникальный объект и используется как уникальная метка в URL-е. ID у него не меняется (вручную он не исправляется).

ID - уникальный признак объекта. Априори он неизменный. 

Вот чтобы о таком и не думать, грамотный продавец будет использовать код производителя

mfym4hxa - уникален для айфона в данном случае, даже для модели из другого региона будет отличаться, если есть желание отслеживать все.
Как уже упомниал, даже у банальной металлочерепицы были свои коды. А сочинать свои - bad idea