Chrome: 65.0.3318.0 Canary
NVDA 2017.4

Steps to repro:
# With NVDA running, visit https://dequeuniversity.com/library/aria/content-feedback/liveregion-playground
# Choose 'Use role defaults' 
# Choose role:status
# Choose Trigger content change: Once
# Press the submit button at least 4 times, pausing between presses to listen for any announcement

Expected: NVDA should announce the new and updated text in the live region

Actual: Nothing happens

Could you run the live region test page and see how many of those regressed, if any?

If none of them regressed, we should add that example to our test page.

It sounds like it might have something to do with changing the role of an existing element, since that's what Aaron's patch affected.

Live Region test page seems to pass. There are instances when NVDA repeats the ending chars of an added message (text node set data and text node replace data) NVDA will says 'succeeded.eeded.eeded' when text is only 'succeeded.'

David, did you get different results with JAWS? And if you left the options alone?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/03a74b82f2a1d041a426d2b13c0a822839ac0794

commit 03a74b82f2a1d041a426d2b13c0a822839ac0794
Author: Aaron Leventhal <aleventhal@chromium.org>
Date: Thu Jan 25 05:43:53 2018

Do not change AX tree for attribute set to same value

Setting an attribute to the same value it had before should never change
the accessibility tree. For example, setting the role attribute to the
same value, although not a recommended authoring practice, has negative
consequences as the accessible object must be recreated to be safe.

In general it is not necessary to update the AX tree unless the value
changes.

Bug:  801293 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: Iab61b3a9a4c30c5183046c9de073e71ab216d6cb
Reviewed-on: https://chromium-review.googlesource.com/876309
Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#531821}
[modify] https://crrev.com/03a74b82f2a1d041a426d2b13c0a822839ac0794/chrome/browser/resources/chromeos/chromevox/cvox2/background/background_test.extjs
[modify] https://crrev.com/03a74b82f2a1d041a426d2b13c0a822839ac0794/third_party/WebKit/Source/core/dom/Element.cpp

JAWS and NVDA behave the same.
The repro steps are fixed, but if I set the example to custom and atomic to false, nothing or short bits of text are announced by both JAWS and NVDA.
Feel free to request an additional bug if this issue is not related to the solution.

@dsexton, that's a different bug.
Note that if you change the custom settings from "text" to "all" you will hear "Added content#X". Then you will hear "Modified" as that text is changed from "Added Content #X" to "Modified Content#X". Chrome thinks that only the first word has changed, even though all of it has been rewritten. I would check with @dmazzoni to see if we have filed that issue yet, because we do know about it.

This issue is fixed.