eventually text alternative computation algorithm of ARIA implementation guide was replaced on new one (http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd_te) and got several problems preserving some old ones:

1) section A

The aria-labelledby attribute takes precedence as the element's text alternative unless this computation is already occurring as the result of a recursive aria-labelledby declaration (in other words, aria-labelledby is not recursive when referenced from another element, so it will not cause loops)

I read this as aria-labelledby is not recursive at all, for example,
<span id="txt1">txt1</span>
<span id="txt2" aria-labelledby="txt1">txt2</span>
<span id="txt3" aria-labelledby="txt2">txt3</span>
It makes me think that aria-labelledby on txt2 is ignored when text alternative is calculated for txt3. If that's what guide says then loops preventing looks like a weak reason because it's enough to ignore last aria-labelledby that causes a loop. Recursive aria-labelledby is implemented in Firefox for years and used on the web and iirc Firefox UI.

On the other hand recursions caused by aria-labelledby and IDRefs attributes from native markup aren't addressed by guide at all. For example,
<label for="input" aria-labelledby="input">label</label>
<input id="input">


aria-labelledby is not recursive anymore, the reason to prevent loops, that's a weak reason because aria-labelledby causing a loop should be ignored

2) section C

current element's role allows "Name From: contents."

Guide should list which ARIA roles allow "Name From contents". If the rule is platform dependent then platform roles should be used instead.

3) section C

It appears the algorithm has lost "name from content if recursive" item. For example,
<p id="p">this is paragraph</p>
<input aria-labelledby="p"/>
Previously paragraph didn't have an accessible name per guide algorithm because it doesn't allow "name from contents" but its content is allowed to be used to build the name of another element so that HTML input was used to pick up paragraph content as accessible name in this example.

4) section C

This same rule may apply to a child, which means the computation becomes recursive and can result in text being collected in all the nodes in this subtree, no matter how deep they are. However, any given descendant subtree may instead collect their part of the text alternative from the preferred markup described in A and B above.

This sounds like browser has too much freedom what must lead to inconsistency between browser implementations. What is that for? I think this is result of getting rid of "name from content if recursive".