This is because ../a/b is interpreted as a relative package path rather than a relative file path, I think.
What should happen in the analogous situation where the module is located at ./a/b and the user runs go list ./a/b?
Should that also be interpreted as a file path?
What if the path includes a ... wildcard, such as ./a/b/... or ./a/... or ../a/... or ../a/b/...?
../a/b is being interpreted as a file path; the problem is with file paths into nested replacement modules in general. I get the same error with an absolute path.
Listing a package in example.com/a works:
$ go list ../a
The wildcard causes a different error, whether or not the module is in a nested replacement. This might be WAI though.
$ go list ../a/...
pattern ../a/...: directory /Users/jayconrod/Code/test/a is outside module root (/Users/jayconrod/Code/test/m)
$ go list ../a/b/...
pattern ../a/b/...: directory /Users/jayconrod/Code/test/a/b is outside module root (/Users/jayconrod/Code/test/m)