Александр Маджугин

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

Тут всего два варианта:
1 Неверное условие и $enum_fields['XML_ID'] никогда не равно 'true' (было бы странно если бы было равно).
2 Условие верное и товар с XML_ID== 'true' есть, но на событии АфтеАпдейт, стоит обработчик который меняет значение на N, деактивируя товар.

Ну наверное можно предложить 2 подхода:

1 Юзать новый ajax компонентов, т.е. писать свои компоненты, в которых реализовывать бизнес-логику и использовать встроенный механизм для обращения к ним с фронта. Вот статья кратенькая: https://verstaem.com/ajax/new-bitrix-ajax/

2 Тупо, в лоб писать скрипты api. Просто скрипты которые просто используют внутренний API проекта, а уже всю логику реализовывать в этом внутреннем API.
Сами скрипты получаются примерно такие, какие-то:

<?
require('.prolog.php');
// добавляем в избранное
	$favorites = \Model\Favorites::getInstance();
if ($_REQUEST['add']) {
	
	$favorites->add2Fav(intval($_REQUEST['add']));
} elseif ($_REQUEST['remove']) {
	$favorites->remove2Fav(intval($_REQUEST['remove']));
} elseif (strlen(trim($_REQUEST['note'])) && $_REQUEST['fav']) {
	$favorites->note2Fav(intval($_REQUEST['fav']),trim($_REQUEST['note']));
}

$arResult['appdata']['user'] = \Model\User::getInstance()->getData();

require('.epilog.php');

Первый подход стильный, модный, молодежный, но и во втором нет ничего криминального, как мне кажется.

В конце концов хочу получить 2 репы, которые ничего друг о друге не знают и общаются через api, сгенерированное тем же Swagger

Классно когда на такие штуки есть бюджет.

Ужасный способ - никогда так не делайте.
Таким подходом вы превращаете систему управления контентом в систему управления страницами.

Какая разница по какому URL открыта ваша страница? Страница должна открываться корректно в независимости от url.

Если ваши div внутри этой страницы - просто пропишите им классы.

Если ваши div внутри какого-то компонента который вызывается из скрипта страницы и из других мест - просто добавьте в компонента параметр в котором передавайте дополнительный класс.

Если ваши div лежат за пределами скрипта страницы (я так подозреваю что это скорее всего ваш случай) используйте отложенные функции:

<div id="one" class="someClass <?=$APPLICATION->ShowProperty('color_class')?>">

И в странице:

<?require($_SERVER["DOCUMENT_ROOT"]."/bitrix/header.php");
$APPLICATION->SetPageProperty('color_class', 'green');
?>

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

js не должен полагаться на готовность DOM который не создается им самим, как за многие годы многих приучил делать jQuery.
Если события назначаются элементам DOM это должен делать тот кто создают html. Если, в данном случае, html создается на сервере с помощью PHP, то и события пусть назначаются на сервере прямо в этом html.

Список новостей разместил в result modifier

Так делать нельзя - в result modifier не должно быть никакого вывода, так как в случае отображения из кэша он не выполняется.

подскажите как мне вывести массив новостей со свойствами в разметку компонента Элементы раздела?

Переместить список новостей в template.php, в нужное место в разметке.

Вот как у меня:

Пользователь подписыается на события связанные с объектом $dctList['UUID']:
\CPullWatch::Add($UserID, $dctList['UUID']);

Отправляем уведомление всем пользователям при событии связанным с объектом с индентификатором $list_uuid

\CPullWatch::AddToStack($list_uuid,
				Array(
					'module_id' => 'list',
					'command' => 'exchange',
					'params' => [
							'provocative' => $dctData['head']['UID'],
							'list_uuid'=> $list_uuid
						]
				)
			);

загрузка модуля:

BX.loadScript('/bitrix/js/pull/protobuf/protobuf.js', ()=>{
					BX.loadScript('/bitrix/js/pull/protobuf/model.js', ()=>{
							BX.loadScript('/bitrix/js/rest/client/rest.client.js', ()=>{
									BX.loadScript('/bitrix/js/pull/client/pull.client.js',()=>{APP.bitrixreinit._pullinit()});
								});
						});
				});

Подписка на события в методе _pullinit:

// подписываемся на события P&P
		BX.addCustomEvent("onPullEvent", function(module_id,command,params) {
			
			if (APP.getConfigParam('uid') == params.provocative) {
				//if ('production' != APP.getConfigParam('mode')) console.log('собственное событие пропущено');
				return;
			}
			if ('exchange' == command) {
				APP.exchange({basis: 'pull', context: params});
			}
		});

		BX.addCustomEvent("onPullStatus", function(status) {
			if ('online' != APP.$store.state.status.push_and_pull
					&& 'online' == status) {
				// не онлайн сменился на онлайн
				//let last_sync_time = APP.$store.state.db.sync.last.time.client || 0
				//let now_time = Date.now()/1000
				//if (now_time - last_sync_time < 30) {
				//	
				//} else {
				//	
				//}
				APP.exchange({basis: 'reconnect'});
			}
			APP.$store.commit("updateStatus",{key:'push_and_pull',data:status})
		});
		
		BX.PULL.start();

Никак - стандартный компонент поиска выводит элементы поиска а не элементы инфоблока - не будет там никакого ['PROPERTIES']['NAME']['VALUE']

Варианта два:
1 получать id элементов инфоблока из элементов поиска и подавать их в виде фильтра на вход news.list им уже выводить элементы.
2 в result_modifier.php шаблона компонента поиска, вынимать недостающие данные.

Я бы выбрал второе.

А почему у вас на каждуй вкладку отдельный компонент? Они так сильно разнятся и их невозможно обобщить до однодного?
Но даже в этом случае у вас должен быть один компонент на все вкладки, который будет подключать разный контент как дочерний компонент по имени:

<div class="tab">
        <component
                v-bind:is="activeTabComponent"
                v-model="values"
            ></component>
    </div>

и передавать в этот дочерний компонент в модель, объект куда будет эмиттить свои данные дочерний компонент.
И вот в этом компоненте вкладки расположите свою кнопку.

Делаем обычную сортировку по SORT, а дальше:

1 в шаблоне выводим только элементы с сортировкой меньше 23, остальные вываливаем в виде данных и рендерим на на странице js'ом (тупой вариант: выводить в тег script с невыполняемым type, и оттуда добавлять js'ом в страницу), страницы по набору элементов будут одинаковые, но порядок каждый раз будет разным. Кэш работает.

2 Добавляем 2-4 дополнительных свойства скажем SORT1, SORT2 и т.д. зафигачиваем эти свойства случайными числами и делаем вторую сортировку по одному из них. При этом выбираем по какому именно рандомно. Получаем 4 кэша с разными страницами по составу.

3 Раз в сутки ночью, агентом переписываем эти допсвойства на другие случайные значения.

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

UPD:
Про решение с двумя компонентами - да просто во втором компоненте на первой странице скройте 22 элемента первые и все. Естественно страница должна быть больше 22 элементов.
Возможно вы сразу возразите, что тогда посетитель в постраничной выборке не увидит эти 22 элемента, поэтому сразу отвечу - вас это вообще не должно волновать, так как у вас посетитель вообще не увидит почти половину каталога (так на вскидку 40-45%) при случайной выборке + пагинации. Вообще пагинация при настоящей случайной выборке полностью лишена смысла.
Рабочее решение близкое к вашим требованиям я выше привел.
Если хотите избавится в нем от того что часть элементов каталога будет невидна при пагинации - передавайте в свойствах пагинации еще и свойство сортировки случайно выставленное на первой стартовой странице.

Я делаю общий шаблон .default, а в остальных шаблонах в хедере:

<?if(!defined("B_PROLOG_INCLUDED") || B_PROLOG_INCLUDED!==true) die();?>
<?include(S_P_LAYOUT.'/header.php');?>
<div class="page">
	<!-- HEADER :: START-->
	<header class="header">
		<div class="container">
			<div class="header__wrapper">
				<a class="header__logo" href="#"><img src="<?=P_IMAGES?>/logotype.svg" alt=""></a>
				
				<?include(S_P_INCLUDES.'/menu-top.php');?>
				
				<div class="header__links">
					<?include(S_P_INCLUDES.'/menu-links.php');?>
				</div>
				
				<button class="hamburger hamburger--spin" type="button" js-hamburger><span class="hamburger-box"><span class="hamburger-inner"></span></span></button>
			</div>
		</div>
	</header>
	<!-- HEADER :: END-->
	<div class="page__content">
		<?$APPLICATION->ShowPanel()?>

и аналогично в футере:

какой-то отличающийся код
<?include(S_P_LAYOUT.'/footer.php');?>

Соотвественно S_P_LAYOUT - это константа с абсолютным путем к папке шаблона .default

Это вариант номер один (и вобще говоря вы можете вложить так сколько угодно шаблонов).

Второй вариант - использовать общие включаемые области во всех шаблонах.

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

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

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

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

Для ускорения загрузки страницы pagespeed предлагает использовать атрибут link rel=preload при подключении CSS.

Вообще-то шрифтов.

Пробовал следовать рекомендации pagespeed и подключать CSS стили такой конструкцией

Вы не правильно распарсили рекомендацию.
Если вы хотите добавить предзагрузку стилей вы должны добавить метатег прелойда:

<link rel="preload" href="/local/templates/.default/css/style.min.css">

А не заменить им загрузку стилей.

Eliminate render-blocking resources - здесь сервис рекомендует убрать блокирующие рендеринг страницы ресурсы, в моем случае он почему то таким ресурсом результирующий CSS файл сайта, куда Битрикс объединил CSS файл стилей шаблона сайта, CSS файлы шаблонов компонентов и системные файлы

Что значит "почему-то"? Потому что это блокирующий ресурс. Вынесете стили страницы и хедера в отдельный файл который вставляйте инлайном в html для пользователей заходящих на сайт впервые в head, и подключайте в конце страницы два файла css - этот (да стили будут дважды загружены) и общий.
А для пользователей заходящих повторно, подключайте только файлы, но уже в начале страницы.

Remove unused CSS - здесь сервис указывает системные CSS и стили шаблона сайта как неиспользуемые, почему так происходит, ведь эти файлы используются в проекте?

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