Description:
When importing a VBP file containing deeply relative reference paths (e.g. ..........\Windows\SysWOW64\stdole2.tlb), the importer resolves them using the Windows extended-length path API, storing the result with a \?\ prefix. The import log correctly warns about this conversion in orange, but the downstream consequence is non-obvious — App.Path at runtime inherits the \?\ prefix, which breaks any code that passes App.Path to subsystems that don't handle extended paths, such as Shell invoking wscript.exe.

Import log warning:
WARNING:
converted relative reference path from ..........\Windows\SysWOW64\stdole2.tlb to \?\Windows\SysWOW64\stdole2.tlb

Observed consequence:
App.Path returns \?\C:\Users\ian\Desktop\TB Labeller instead of C:\Users\ian\Desktop\TB Labeller, causing Shell calls that pass App.Path as part of a command string to fail at runtime with 800A01A8 Object required.
The issue only manifests on code paths that pass App.Path to subsystems without \?\ support — making it a difficult-to-diagnose migration trap that may not surface during initial testing.

Root cause:
For well-known system type libraries like stdole2.tlb, the importer should substitute the known absolute path (C:\Windows\SysWOW64\stdole2.tlb) directly rather than resolving a relative path chain via the extended path API.

Workaround:
Before importing, edit the .vbp in a text editor and replace relative references with their absolute paths. Alternatively, strip the \?\ prefix from App.Path at runtime:

vbDim sPath As String
sPath = App.Path
If Left(sPath, 4) = "\?" Then sPath = Mid(sPath, 5)
Environment: twinBASIC BETA 982, Windows 10, project imported from VB6 .vbp