I still have some work to do here for $dynamic*, but I'm going to wait until #1589 is done so I can rebase on that.

Just did a close/open to rekick the build. It had been a while and couldn't do it manually.

Reviewed the changes in #1589, and they seem to align with the rest of what I've updated here, so I'm going to leave $dynamic* as it is.

...I still really dislike the way dynamic scope is defined. I think it should be the stack of schema resources and not include subschemas.

I agree, and this is already how we define dynamic scope (unless you're intending to change that?) -- we say elsewhere in the spec, when processing $dynamicRef [emphasis mine], "...the initial URI MUST be replaced by the URI (including the fragment) for the outermost schema resource in the dynamic scope that defines an identically named fragment with "$dynamicAnchor".

Therefore, in my implementation, the current URI is pushed to the dynamic_scope stack (the array that is searched when processing $dynamicRef) only when processing the $id keyword, not for every subschema.

I can't see any usecases for wanting other, non-resource, subschemas to be stored in the dynamic scope.

I've updated to use resources. (This is actually what we agreed on when @jviotti was writing his posts on scopes.)

It does raise one question, though: what if evaluation starts at a subschema? I suppose the dynamic scope is still the resource, but the evaluation path would still start from the subschema? This is how I have it now, and I could change it if we decide something else.

I desperately hope we wouldn't ever add another keyword that uses dynamic scope. - @jdesrosiers

I don't know. I think if explained properly (which is what this change is for), dynamic scopes could be utilized by others that need it. I think it's a powerful concept and it gives extensions another trick.