SYSTEM-RELATIVE-PATHNAME has counterintuitive behavior on systems with PATHNAME

Here's a system definition I have:

(defsystem shop2/openstacks
    :depends-on (:shop2)
  :serial t
  :pathname "examples/openstacks-adl/"
  :components ((:file "package")
               (:file "domain")))

Here's what ASDF system-relative-pathname returns:

SHOP-REPLAN-TESTS> (asdf:system-relative-pathname "shop2/openstacks" "")
#P"/Users/rpg/projects/laplata/lmco-laplata/planner_distro/ext/shop2/"

What I expected it to return:

#P"/Users/rpg/projects/laplata/lmco-laplata/planner_distro/ext/shop2/examples/openstacks-adl/"

So the semantics of this function are what I would expect from

SYSTEM-DEFINITION-RELATIVE-PATHNAME

not

SYSTEM-RELATIVE-PATHNAME

I.e., it's

(defun* (system-relative-pathname) (system name &key type)
    "Given a SYSTEM, and a (Unix-style relative path) NAME of a file (or directory) of given TYPE,
return the absolute pathname of a corresponding file under that system's source code pathname."
    (subpathname (system-source-directory system) name :type type))

Note that the docstring is ambiguous because "system's source code" could mean "the source code that defines the system object" [which is what is done here] or "the source code that defines the system"

This definition gives the behavior I expect:

(defun system-relative-pathname (system name &key type)
    "Given a SYSTEM, and a (Unix-style relative path) NAME of a file (or directory) of given TYPE,
return the absolute pathname of a corresponding file under that system's source code pathname."
    (subpathname (component-pathname (find-system system)) name :type type))

I think it would be best to make this modification, although I concede it could cause some breakage.