I'm leaning towards thinking that this problem is not specific to SliceViewAnnotations.
If the annotations are disabled, then I still get an error if trying to load scalar volume from DICOM:

Traceback (most recent call last):
File "C:/d/S4D/Slicer-build/lib/Slicer-4.4/qt-scripted-modules\DICOMLib\DICOMWidgets.py", line 516, in loadCheckedLoadables
if not plugin.load(loadable):
File "C:/d/S4D/Slicer-build/lib/Slicer-4.4/qt-scripted-modules/DICOMScalarVolumePlugin.py", line 304, in load
volumeNode = self.loadFilesWithArchetype(loadable.files, loadable.name)
File "C:/d/S4D/Slicer-build/lib/Slicer-4.4/qt-scripted-modules/DICOMScalarVolumePlugin.py", line 299, in loadFilesWithArchetype
return(volumesLogic.AddArchetypeScalarVolume(files[0],name,0,fileList))
AttributeError: AddArchetypeScalarVolume

Digging deeper, it seems that many python modules are out of reach. For example if I want to explicitly import volumes logic, then I get this:

import vtkSlicerVolumesModuleLogic
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "C:/d/S4D/Slicer-build/lib/Slicer-4.4/qt-loadable-modules/Python\vtkSlicerVolumesModuleLogic.py", line 5, in <module>
from vtkSlicerVolumesModuleLogicPython import *
ImportError: No module named vtkSlicerVolumesModuleLogicPython

Same happens with logic and MRML for other loadable modules too. The reason of this is beyond my knowledge.

1. sys.path did not include ...loadable-modules/Debug, but only the one without Debug
2. Specified working directory in VS project settings, problem solved
3. Removed working directory (i.e. revert to state where it failed), still worked!

Suspicion: wrong SlicerLauncherSettings.ini file is found, or wrong launcher is executed.
Next time we have this issue: I use a batch file that starts VS with environment, contains '.\S4D\Slicer-build\Slicer.exe --VisualStudio --launcher-no-splash'. This uses relative path and may result in wrong automatic finding of ini or other files. Next time try cd S4D/Slicer-build then Slicer.exe instead of .\S4D\Slicer-build\Slicer.exe

It may be worth adding print statement and/or break point to qSlicerCoreApplicationPrivate::discoverSlicerHomeDirectory()

The issue came back with a clean build, and cannot fix it with the steps I did before.

qSlicerCoreApplicationPrivate::discoverSlicerHomeDirectory() returns the proper Slicer-build directory

Can your start Slicer outside of Visual Studio using the launcher ?

Yes, and it works as expected. Somehow the sys.path is different if I start it from VS (launching the Slicer-App project after starting VS with the launcher). The difference that causes the problems is that Slicer-build/lib/Slicer-4.4/qt-loadable-modules/Debug is missing (or Release, because it doesn't work with release either)

Also there is a very strange entry in the faulty sys.path:
'C:\d\S4R\Slicer-build\bin\Release:C:\d\S4R\Slicer-build\bin\Python:C:\d\S4R\Slicer-build\lib\Slicer-4.4:C:\d\S4R\Slicer-build\lib\Slicer-4.4\qt-loadable-modules:C:\d\S4R\Slicer-build\lib\Slicer-4.4\qt-loadable-modules\Python:C:\d\S4R\Slicer-build\lib\Slicer-4.4\qt-scripted-modules:C:\d\S4R\VTKv6-build\bin\Release\:C:\d\S4R\VTKv6-build\Wrapping\Python:C:\d\S4R\CTK-build\CTK-build\bin\Release\:C:\d\S4R\CTK-build\CTK-build\bin\Python'

Apparently it's constructed in a wrong way, there is no single quota and comma, but a colon. Strange...

Sorry, I commented to the wrong ticket. I'm removing it and reopening this one.

The problem is that PYTHONPATH is made empty by the function qSlicerExtensionsManagerModelPrivate::removeExtensionPathFromLauncherSettings at line 565. This should not be done, as empty is never good. Also I'm not sure this variable should be saved in the Slicer-NNNNN.ini, but there might be some legitim reason.

Second, the "strange" invalid merged one-line path comes from qSlicerCoreApplicationPrivate::setPythonEnvironmentVariables(), where this variable is constructed at line 527, and it is done linux-style. I understand that many core developers use linux, but most users use Windows, so that platform should be considered at all times.

All this is done because Slicer "thinks" I removed an extension (due to my own ini file magic that I do to make my life easier by not manually adding all the module paths when changing Slicer revision that happens awfully often), this is why I set it related to 0003876, which is basically the same issue.

Jc, can you please comment on these? Thanks!

Fixed the "extension removed" issue (just locally so that it doesn't occur, not the root cause), but the sys.path is still corrupt, so not the same issue as 0003876, still related. Investigating why the path is wrong

This problem has not occurred in the last few months. I'm pretty sure it was due to the extension removal problem (and maybe some old windows disease too).

The problem seems to be gone now, closing the issue