Different namespace behavior /files/list_folder and /files/search_v2 API calls, bug?

Hi there!

I am encountering a peculiar issue with the /2/files/search_v2 call in combination with team namespace ids, and I am not sure if this is a bug or the expected behaviour of the API.

Consider the following team space configuration:

/Team Dropbox (1)
/Team Dropbox/Sarah (2)
/Team Dropbox/Sarah/Documents
/Team Dropbox/Sarah/Documents/Example.doc
/Team Dropbox/John (3)

When I make a /2/files/list_folder call using {"path":"/Documents"} with the Sarah account, I get the contents of the /Documents folder, including the file Example.doc. This is all perfectly fine.

However, if I also make a call to /2/files/search_v2 using {"query":"Example","options":{"filename_only":true,"path":"/Documents"}} with the Sarah account, I get no results.

After some testing I noticed that the /2/files/list_folder call implicitly uses the home folder of Sarah (home_namespace_id: 2) to list the content. However, the /2/files/search_v2 API call uses the root folder (root_namespace_id: 1). So the search call won't return any results in this case because the /Documents path provided isn't correct.

To resolve this, I can use {"query":"Example","options":{"filename_only":true,"path":"/Sarah/Documents"}} where I add the Sarah home folder in the path. Or I can add the header Dropbox-API-Path-Root: {".tag":"namespace_id","namespace_id":"2"} to the original call. When I do this, the file Example.doc is returned in the search results.

Why are the /files/list_folder and /files/search_v2 calls using a different root/home location? Or is it a bug and should the home_namespace_id (2) also be used implicitly for the /files/search_v2 call, as with the /files/list_folder call? Or am I missing something here?