Knockout: "Você não pode aplicar vinculações várias vezes ao mesmo elemento" durante a travessia de uma árvore DOM após applyBindings

Tente chamar ko.cleanNode(domNode) antes de ko.applyBindings

Portanto, na verdade, se eu chamar cleanNode, todas as assinaturas serão dispostas de forma contrária ao resultado desejado.

Mas você obtém essa exceção apenas porque chama applyBindings várias vezes; cada vez que você chamar esse método, as assinaturas serão recriadas. Então, acredito que essa abordagem deve funcionar:

ko.cleanNode(element);
ko.applyBindgings(viewModel, element);

Infelizmente, o cenário de que você está falando não é o meu caso. Não chamo applyBindings várias vezes. No meu caso, ele é chamado exatamente uma vez. O problema é que o Knockout atravessa recursivamente a árvore DOM e, quando encontra um nó, que é processado na mesma pilha de chamadas, o erro é acionado.
Isso se deve ao fato de que o nocaute atravessa a árvore DOM "em profundidade" e, quando movo o elemento processado para cima, o nocaute da hierarquia do DOM encontra esse elemento mais uma vez.

Provavelmente, você pode corrigir isto retornando { controlsDescendantBindings: true } a partir do seu manipulador de ligação init função. Consulte http://knockoutjs.com/documentation/custom-bindings-controlling-descendant-bindings.html

Oh, eu entendi o problema. Você realmente precisa mover o elemento existente para outro lugar? É um comportamento um pouco estranho. Parece algum tipo de hacks. Você cria uma instância de mecanismo de modelo anônimo apenas porque deseja chamar o método de nós. E então você chama renderTemplate que também cria um objeto de modelo anônimo ... De qualquer forma, até mesmo sua solução pode ser corrigida usando mais uma ligação personalizada stopBinding . Você pode verificar o exemplo de trabalho: http://jsfiddle.net/ESCT4/12/ .
De qualquer forma, recomendo reconsiderar esta solução, ela parece muito complicada (eu nem entendo o que você deseja alcançar usando esta ligação overlay . Parece que você colocou parte das responsabilidades de ViewModel em View), mas depende de você

Vou encerrar isso porque é por design (e tão antigo que é improvável que ainda seja uma preocupação ativa). Por favor, reabra se alguém discordar!