What happens?

p. 117 is contradictory with regard to how the idShortPath url-segment should be encoded. Here's the quote with relevant parts marked bold.

Note 1: to avoid problems with IRI values in URLs, the identifiers shall be base64url-encoded before using them as
parameters in the HTTP-APIs. IdshortPaths are base64url-encoded to also allow square brackets.
Note 2: in the example above, “aHR0cHM6Ly9hZG1pbi1zaGVsbC5pby9zYW1wbGVTTQ” is the base64url-encoding
of “https://admin-shell.io/sampleSM”, “sme1.sme2%5B0%5D.p1” is the URL-encoding of “sme1.sme2[0].p1”,
and “sme1.sme2%5B0%5D” is the URL-encoding of “sme1.sme2[0]”

Why is this wrong?

It's unclear how this shall be implemented. It's either base64Url- or Url-encoding.

How should it be fixed?

I don't have an opinion what's better. Url-encoding is more readable but being consistent in encoding technology would also be nice.
...

• I have signed the required Developer Certificate of Origin (DCO) already.