1) O multithreading é extremamente difícil e, infelizmente, a maneira como você apresentou essa idéia até agora implica que você está subestimando seriamente o quanto é difícil.
No momento, parece que você está simplesmente "adicionando tópicos" à linguagem e se preocupando em como torná-la correta e com desempenho posterior. Em particular:
if two tasks try to access a variable concurrently it gets marked atomic and they contend for access.
...
I agree that atomic variables won't solve everything, but working on a solution for the synchronisation problem is my next goal.
Adicionar threads ao Javascript sem uma "solução para o problema de sincronização" seria como adicionar inteiros ao Javascript sem uma "solução para o problema de adição". É tão fundamental para a natureza do problema que basicamente não adianta discutir se o multithreading vale a pena ser adicionado sem uma solução específica em mente, não importa o quanto queiramos.
Além disso, tornar todas as variáveis atômicas é o tipo de coisa que provavelmente faz com que um programa multithread execute um desempenho pior do que sua contraparte singlethreaded, o que torna ainda mais importante testar o desempenho em programas mais realistas e veja se você está ganhando alguma coisa ou não.Também não está claro para mim se você está tentando manter os threads ocultos do programador node.js ou se planeja expô-los em algum momento, efetivamente criando um novo dialeto de Javascript para programação multithread. Ambas as opções são potencialmente interessantes, mas parece que você nem sequer decidiu qual delas você está mirando ainda.
Então, no momento, você está pedindo aos programadores que considerem a mudança de um ambiente singlethreaded para um novo ambiente multiencadeado que não tenha solução para o problema de sincronização e nenhuma evidência que melhore o desempenho no mundo real e aparentemente nenhum plano para resolver essas questões.
É provavelmente por isso que as pessoas não te levam a sério.
2) A simplicidade e robustez do loop único evento é uma vantagem enorme .
Programadores em Javascript sabem que a linguagem Javascript é "segura" de condições de corrida e outros bugs extremamente insidiosos que afetam toda a programação genuinamente multithread. O fato de que eles precisam de argumentos strongs para convencê-los a desistir dessa segurança não os torna de mente fechada, isso os torna responsáveis.
A menos que você possa, de alguma forma, manter essa segurança, qualquer pessoa que queira mudar para um node.js multithread seria provavelmente melhor mudar para um idioma como o Go, projetado para aplicações multithreaded.
3) O Javascript já suporta "threads de segundo plano" (WebWorkers) e programação assíncrona sem expor diretamente o gerenciamento de threads ao programador.
Esses recursos já resolvem muitos casos de uso comum que afetam os programadores de JavaScript no mundo real, sem abrir mão da segurança do loop de evento único.
Você tem algum caso de uso específico em mente que esses recursos não resolvem e que os programadores de JavaScript querem uma solução? Em caso afirmativo, seria uma boa ideia apresentar seu node.js multithread no contexto desse caso de uso específico.
P.S. O que convenceria mim a tentar mudar para uma implementação node.js multithread?
Escreva um programa não-trivial em Javascript / node.js que você acha que se beneficiaria com multithreading genuíno. Faça testes de desempenho neste programa de amostra no nó normal e no nó multithread. Mostre-me que sua versão melhora o desempenho em tempo de execução, a capacidade de resposta e o uso de vários núcleos em um nível significativo, sem apresentar nenhum erro ou instabilidade.
Depois de fazer isso, acho que você verá as pessoas muito mais interessadas nessa ideia.