This is a follow-up of #1312 which I just merged; I should have asked this before merging.

The ordering of step 2's "later duplicates omitted" and step 3's removal of different-origin browsing contexts seems potentially suspect. Consider the following set of child browsing contexts of the active document, where the current origin is example1.com:

• name = "a", origin = example2.com
• name = "a", origin = example1.com

With this set, the result of running the algorithm after step 2, by my reading, is:

• name = "a", origin = example2.com

(later duplicates being omitted. Assuming duplicates means duplicate names?)

Then, after step 3, we remove that list entry, because it is not same-origin. The result is that there are no child browsing context names. This seems unlikely to be intended.

Suggested solutions:

• Clarify what "later duplicates being omitted" means. I don't think it's possible to have duplicate browsing contexts, so if this is based on "browsing context identity", then this sentence should be removed. If it's based on name, it should be clarified, e.g. "including only the first child browsing context with a given name if multiple child browsing contexts have the same one."
• Is this behavior correct? If so, then clarification suffices. If not, then I'd suggest doing the duplicate name filtering at the last step. (Perhaps coupled with Clarify how "child browsing contexts" works #1336's suggestion of defining "a Window object's same-origin child browsing contexts"?)