Install pywin32 from PyPI and then try to do:

import win32api

Which fails. The language server prints:

[Info  - 2:29:32 PM] Interpreter search paths:
[Info  - 2:29:32 PM]     c:\python37\dlls
[Info  - 2:29:32 PM]     c:\python37\lib
[Info  - 2:29:32 PM]     c:\python37
[Info  - 2:29:32 PM]     c:\users\jabaile\test_projects\win32thing\venv
[Info  - 2:29:32 PM]     c:\users\jabaile\test_projects\win32thing\venv\lib\site-packages
[Info  - 2:29:32 PM]     c:\users\jabaile\test_projects\win32thing\venv\lib\site-packages\win32
[Info  - 2:29:32 PM]     c:\users\jabaile\test_projects\win32thing\venv\lib\site-packages\win32\lib
[Info  - 2:29:32 PM]     c:\users\jabaile\test_projects\win32thing\venv\lib\site-packages\pythonwin

Note that win32 is in site-packages and lib is inside of win32.

This package ships multiple modules, and uses a pth file to add those search paths:

# .pth file for the PyWin32 extensions
win32
win32\lib
Pythonwin

The module win32api is located in the win32 directory. However, due to the ordering of the paths (site-packages comes first), we end up in a scenario where only this works:

import win32.win32api
# or equivalently to the original example
from win32 import win32api

Because we've already "carved" out site-packages, and any module below it must be fully specified, even though a later search path allows the module to have a second name.

This is a concrete example of similar issues we have with extraPaths on user code, but due to the use of pth files here to add search paths, this breaks out into library code.