Clarification regd. native-search-paths and search-paths

[Suhail Singh <suhailsingh247@gmail.com>]

Hello Guix,

Per the manual:

#+caption: [[info:guix#Search Paths][guix#Search Paths]]
#+begin_quote
  What this ‘native-search-paths’ field says is that, when the ‘python’
  package is used, the ‘GUIX_PYTHONPATH’ environment variable must be
  defined to include all the ‘lib/python/3.9/site-packages’
  sub-directories encountered in its environment.  (The ‘native-’ bit
  means that, if we are in a cross-compilation environment, only native
  inputs may be added to the search path; *note ‘search-paths’: package
  Reference.)
#+end_quote

Does "used" above refer to runtime usage?

If so, in that example, why is native-search-paths used instead of
search-paths?  I would think that in order to have appropriate runtime
behaviour while supporting cross-compilation, we would want to use
search-paths instead.  And yet, it seems, the recommendation seems to be
to favour native-search-paths in general:

#+caption: [[info:guix#package Reference][guix#package Reference]]
#+begin_quote
  As for inputs, the distinction between ‘native-search-paths’
  and ‘search-paths’ only matters when cross-compiling.  In a
  cross-compilation context, ‘native-search-paths’ applies
  exclusively to native inputs whereas ‘search-paths’ applies
  only to host inputs.

  Packages such as cross-compilers care about target inputs—for
  instance, our (modified) GCC cross-compiler has
  ‘CROSS_C_INCLUDE_PATH’ in ‘search-paths’, which allows it to
  pick ‘.h’ files for the target system and _not_ those of
  native inputs.  For the majority of packages though, only
  ‘native-search-paths’ makes sense.
#+end_quote

How does one determine which of native-search-paths or search-paths is
appropriate in a given context?

-- 
Suhail