Aetae

В первом случае ты сортируешь уже отсортированный массив повторно(при каждой сортировке начальное состояние разное), во втором ты сортируешь каждый раз новый(начальное состояние одно и то же).

Использование Math.random в sort в любом случае не даст нормального распределения, т.к. под капотом используется определённый оптимизированный алгоритм сортировки, к тому же браузерозаивисимый и разный для разных случаев.
Как это всё влияет на конечный результат - одному богу известно (или дотошному математику, который засядет с сырцами браузера и распишет километровые формулы, да).
Если нормальное распределение получилось на практике - это совпадение, а не гарантия, что так и будет впредь.

Факт в том, что не надо использовать метод sort ни для чего, кроме его предназначения - детерминированной сортировки.

Используй нормальный алгоритм перемешивания и будет тебе счастье.

html, body {
  margin: 0;
  padding: 0;
}

console.log.toString()
Сайт подменяет консоль.

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

// @run-at document-start
const myConsole = window.console;

Если нет, но очень надо - можешь создать фрейм и забрать консоль оттуда.)

о какой рендер функции идет речь?

render-function

Это более низкоуровневый вариант работы с vue, вместо использования <template>.(под капотом <template> компилируется в render-функцию)

Render-функцию можно возвращать из setup, можно класть в свойство render.
При script setup, можно сделать так:

<template>
  <div>
    <render/>
  </div>
</template>

<script setup lang="ts">
  import { h, useSlots } from 'vue'

  const slots = useSlots();
  const render = () => {
    return h('div', slots.default());
  };
</script>

Но не нужно в подавляющем большинстве случаев. Мешать всё в одну кучу - весьма опасно.

1. Typescript тут не при чём.
2. Если ты используешь метод из "camera-hardware", то проблема очевидна. Если из "camera-software", то хз, должно работать.

Ну собсно по хардкору:
1. Invalidate Caches если ещё не сделал.
2. Закрыть, удалить папку .idea, открыть чтоб распарсил заново.
3. Создать новый проект с заведомо рабочим конфигом и перекидывать туда кусками пока не сломается и так найти виновника.

Одинаковая структура при разных реализациях - это больно и малореально. Существуют css\html-only дизайн системы, которые можно брать и реализовывать на любом фреймворке, но это тот ещё геморрой без особого выхлопа.

Мне кажется вам стоит решить чего вы будете-придерживаться впредь, а что легаси, и вынести таки все компоненты одной актуальной версии(vue2 или vue3) в библиотеку, скомпилировав её в режиме web-components. Веб компоненты вы сможете подключать куда угодно, ценой лишних 100кб на непрофильный vue-runtime в случае несовпадения.

export default defineComponent({
  name: 'CounterButton',
  props: {
    count: {
      type: Number,
      default: 0
    }
  },
  template: `<button type="button" @click="counter++">{{counter}}</button>`,
  emits: ['update:count'],
  setup(props, context) {
    const innerCounter = ref(props.count);
    watch(() => props.count, (value) => innerCounter.value = value);
    return {
      counter: computed({
        get: () => innerCounter.value,
        set: (value) => context.emit('update:count', innerCounter.value = value)
      })
    }
  }
})

Трогать родной BehaviorSubject не стоит, не одному тебе потом с ним работать.

Ты мог бы написать свой вариант довольно просто таким образом:

class DistinctBehaviorSubject<T> extends BehaviorSubject<T> {
  next(value: T) {
    if (this.value !== value)
    	super.next(value);
  }
}

Но я на вскидку не скажу какие тут могут быть подводные камни.)

На вскидку не вижу проблемы, что-то такое должно сработать:

function doSomething(param: string, value: unknown) {
  console.log('doSomething', param, value);
}

function WebworkerParam(param: string){
  return (target: any, key: PropertyKey) => {
    let subscription: Subscription;
    let innerValue: any;

    Object.defineProperty(target, key, {
      get() {
        return innerValue;
      },
      set(value) {
        if (subscription)
          subscription.unsubscribe();

        if(value instanceof BehaviorSubject)
          subscription = value.subscribe(newValue => doSomething(param, newValue));
        else 
          doSomething(param, value);

        innerValue = value; 
      }   
    })
  }
}

class User {}

interface Types {
  number: number;
  dog: string; 
  user: User
}

function add<K extends keyof Types>(type: K): Types[K] {}

На каждое срабатывание nextStep ты вешаешь новый слушатель keydown.
10 буковок ввёл - 10 слушателей весит. Работать это говно, соответственно, может как угодно.

И вообще нефиг смешивать vue и работу с сырым dom.

Никаких setTimeout точно.
Просто при каждом поступающем сообщении создаёте задачу на временную метку(можно с помощью совета Станислав Макаров) если такой ещё нет, которая в указанное время запросит все записи с такой меткой и выполнит с ними нужное действие.
Метку и, соответственно, запрос можно создавать с округлением в размере допуска.
В базе естественно всё это дело надо индексировать и складывать для удобства таких запросов.

Не надо ничего никуда вставлять.
eval(res.data.notification.FRONT_SCRIPT)

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

(this.$refs.text as HTMLInputElement).focus();
TypeScript, увы, не знает типа твоего ref.

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

Однако в целях поддержки лекаси ты можешь просто подменить тип, что-то вроде:

type MethodNames<T extends string> = `get${T}s` | `create${T}` | `get${T}`;

interface IAPI {
  new <T extends string>(type: T, url: string): {
    [K in MethodNames<T>]: Function
  }
}

export default API as unknown as IAPI;

сработает как надо. Естественно ты можешь доработать интерфейс IAPI до полного совпадения.

При декларации самого класса ты максимум можешь добавить неспецифичную index signuture, условно:

type MethodNames<T extends string> = `get${T}s` | `create${T}` | `get${T}`;
class API {
  [key: MethodNames<string>]: Function

  _url;

  constructor(type: string, url: string) {
    this._url = url;

    this[`get${type}s`] = this._readMany;
    this[`create${type}`] = this._create;
    this[`get${type}`] = this._read;
  }

  _readMany(params = {}) {
    const options = getApiOptions(Method.GET);
    const url = new URL(this._url);
    url.search = new URLSearchParams(params);
    
    return fetch(url.toString(), options);
  }

  _create(body) {
    const options = getApiOptions(Method.POST, body);
    
    return fetch(this._url, options);
  }

  _read(id) {
    const options = getApiOptions(Method.GET);
    
    return fetch(`${this._url}/{id}`, options);
  }
}

Но это уже будет не так удобно и чётко.

Ну очевидно, что NavLink не принимает функцию в качестве children. Могу предположить, что код у тебя для одной версии роутера, а используется другая.

Ну очевидно, что надо хранить реги уже скомпилированными, исключив шаг re.compile из цикла.
Далее можно вести статистику и поднимать(тем или иным образом) более частые реги в массиве повыше.
Ну а дальше уже использование каких-нить низкоуровневых либ, но ИМХО и первого должно хватить.)
...Ещё можно распараллелить, но хз какие у тебя там ресурсы по ядрам.
...Ещё можно склеить эти 10к регулярок в одну и прогнать через глубокий оптимизатор регулярок. Если результат выйдет адекватным, то можно предварительно проверять текст на соответствие такой единой оптимизированной регулярке. Но это, понятное дело, сильно зависит от твоего набора.

Компоненты могут быть переиспользованы. Но помимо переиспользуемых компонентов, которые действительно не должны лезть ни в какой vuex, есть собственно и страницы самого приложения\сайта. Они никогда не будут переиспользованы, кроме как в том же самом приложении и у них должно быть общее состояние(не может не быть).