Perhaps the reason of the question is a chrome bug.

document.body.innerHTML = '<a id="test">old value</a>'

var a = document.getElementById('test')
//  cache old TextNode
var cacheTextNode = a.childNodes[0]
// update innerHTML
a.innerHTML = "new value"

// output old TextNode.parentNode
console.log(cacheTextNode.parentNode)

// In chrome(60)
=> null

// In chrome(55) & chrome(47)
=> <a id="test">new value</a>

In old chrome version(55), the ch.elm point to the new TextNode and the parentNode is not null

In last chrome version(60), the ch.elm point to the old TextNode and the parentNode is null

The el textNode should not be in the dom tree here.

And it seems that only text node will get the buggy behavior.

Maybe we could attach an extra info to the parent node when patching the dom props in updateDomProps to workaround the chrome bug, e.g. check the oldVnode's children and mark the parent element when it only contains a text node.

I honestly don't think we should cater to such obvious buggy behavior in an outdated version of a browser (it's 6 versions behind). The fix also lets platform-specific code leak into the core patching algorithm.

If for some reason your app must be run in an older version of Chrome, you can give the two divs different keys to work around the behavior.

Update: it seems old Chrome has a higher market share than I thought...

This fix doesn't take node type (shouldn't it be 'text' only?) into account and causes other applications to fail: ckeditor/ckeditor5#2016 (comment). The problem was that all inner DOM nodes of the Vue component are expected to be managed by the editor.