Change:
Can you explain how the test scripts work and how to interpret the output, please?
I haven't done the work to make this a real CI script. You clone the JPC to a directory parallel to where you cloned the I-D repo. kdrfc draft-ietf-jsonpath-URL sh URL ruby scripts/test-abnf-URL > scripts/test-abnf-URL 2>&1 ruby scripts/test-abnf-URL > scripts/test-abnf-URL 2>&1 ruby scripts/test-abnf-URL > scripts/test-abnf-URL 2>&1 ruby scripts/test-URL > scripts/test-URL 2>&1 Compare the output with the checked-in output. (The output contains all parse failures, including the intentional ones. The word FAIL tells you about unexpected output.) An output that says "successfully completed" at the end has done exactly that.
~JPC?~ oh... json path comparison
Is this something that should be in the same repo as the spec? Seems like it should be with a test suite. Or do we plan to remove it before publication?
Indeed -- URL mentioned json-path-comparison (which I call JPC) and jsonpath-compliance-test-suite (which I call CTS). Of course I'd love to get more test data...
This repo contains everything that is needed to work on the spec document. Testing the ABNF in the spec document is a typical case for including tests with the code. It's testing the document. The information in there can possibly be used for building test suites, but I'd rather use the original data in JPC and CTS (which already is a test suite). The test data specifically collected (test-URL) could indeed be used for further testing, but it probably makes more sense to include sample documents and sample query results with that (which were not needed to test just the ABNF). We publish the spec (as an RFC). The repo that creates the spec is public, but not "published" in the stricter sense.
Two objectives: (1) aesthetic cleanup, e.g.: URL (2) more tests, e.g., to be built from query corpora we can find
Looks plausible. I haven't reviewed or run the Ruby code.

Discussion:
Shorthand notations are also provided for when there is a single wildcard or name selector. <del> The "dot-wildcard-shorthand" is shorthand for "[*]". </del> <ins> ".*", a "child-segment" directly built from a "wildcard-selector", is shorthand for "[*]". </ins> <del> A "dot-member-name-shorthand" of the form ".<member-name>" is shorthand for "['<member-name>']", but can only be used with member names that are composed of certain characters.  Thus, for example, "$.foo.bar" is shorthand for "$['foo']['bar']" (but not for "$['foo.bar']"). </del> <ins> ".<member-name>", a "child-segment" built from a "member-name- shorthand", is shorthand for "['<member-name>']".  Note that this can only be used with member names that are composed of certain characters, as specified in the ABNF rule "member-name-shorthand". Thus, for example, "$.foo.bar" is shorthand for "$['foo']['bar']" (but not for "$['foo.bar']"). </ins> 2.7.1.2.

Shortand notations are also provided that correspond to the shorthand forms of the child segment. <del> The "descendant-wildcard-shorthand" is shorthand for "..[*]". </del> <ins> "..*", the "descendant-segment" directly built from a "wildcard- selector", is shorthand for "..[*]". </ins> <del> A "descendant-member-name-shorthand" of the form "..<member-name>" is shorthand for "..['<member-name>']". </del> <ins> "..<member-name>", a "descendant-segment" built from a "member-name- shorthand", is shorthand for "..['<member-name>']".  As with the similar shorthand of a "child-segment", note that this can only be used with member names that are composed of certain characters, as specified in the ABNF rule "member-name-shorthand". </ins> Note that ".." on its own is not a valid segment.