Hard-coded Qt Path [Windows only ?]

Under Windows, in Qt 4.8.4 the path in which Qt-plugins components (such as "iconengines" and "imageformats", used by MuseScore) are searched is hard-coded in Qt core dll (QtCore4.dll).
See http://qt-project.org/doc/qt-4.8/deployment-windows.html (Qt plugins section)
Some required dlls are thus first searched inside the Qt plugins folder and only afterwards inside MuseScore bin folder.
Therefore, if the user has an installation of the same Qt version, but different from the one used for the compilation of MuseScore (for example, compiled with a different compiler, e.g. gcc-4.4 or gcc-4.7), even if Qt is not in the PATH environment variable there may be problems. This affects also version 1.3, see http://musescore.org/en/node/20966
[Indeed, by renaming the folder C:\Qt\4.8.4\plugins, version 1.3 no more displays problems or crashes.]
This possible problem is still present in 2.0 pre-release.
Output of self-compiled version 9285d6a with gcc-4.8.0-dwarf-rev1 and Qt-4.8.4, Windows XP Professional SP3:
> set PATH=
> mscore.exe -d
Debug: global share: <D:/MuseScore/win32install/>
Debug: configured localeName <en_US>
Debug: load translator <D:/MuseScore/win32install/locale/mscore_en_US>
Debug: load translator <qt_en_US> from <D:/MuseScore/win32install/locale/>
Debug: load translator <qt_en_US> failed
Debug: DPI 96.000000
InitTime : multimedia timer resolution set to 1 milliseconds
Cannot connect to named pipe after wait = \\.\pipe\server_jack_default_0 err = 2
Cannot connect to server request channel
Execution of JACK server (command = "C:/Program Files/Jack/jackd.exe") failed: No such file or directory
Cannot connect to named pipe after wait = \\.\pipe\server_jack_default_0 err = 2
Cannot connect to server request channel
jack server is not running or cannot be started
Open error: is JACK server running?
Debug: using PortAudio Version: PortAudio V19-devel
Debug: Init midi driver failed
Debug: LibraryPath: <C:/Qt/4.8.4/plugins>
Debug: LibraryPath: <D:/MuseScore/win32install/bin>

This is a Qt issue. Could adding a custom (relative) librarypath be a work-around? Or maybe better change search order with setLibraryPaths() ?

It seems also Qt-5 behaves similarly: http://qt-project.org/doc/qt-5.0/qtdoc/deployment-windows.html#qt-plugi…