plugins search path problems

I've deployed a Qt based application with all necessary dll and plugin files, the Qt Version is 5.3.2 for MSVC2010. A user of my app told me, that the app crashes on startup because of the qwindows.dll.

So, I've checked all my dll and plugin files again, but everything is fine. I found out, that the user has also a Qt installation on his system, installed via the online installer, like me. And I've found out, that my app tries to load the qwindows.dll from his installation folder, instead of the local application folder. I can see the same behavior on my system, too, the first search path is the hard-coded path in QtCore.

That's not what I would expect, but anyway, why the app crahes, when the other user has the same dll on his system?

I've found out, that his version is in fact another one, he has used the online installer to install 5.3.1 and I have installed 5.3.2. So, the path on my system is the same as on his one: C:\Qt\5.3\msvc2010_opengl, but the binaries are different. That's the reason why the app finds the dll (but the wrong one (5.3.1)) and does not fallback to the local one (5.3.2).

I'm wondering about this problem, I seem to remember that all dll and plugin files will be searched locally first. So, why do you have changed the order of search paths? Or is it a bug?

I've checked the Qt documentation and there are obviously contradictory statements:

On page "Deploying Plugins" there is written

When the application is run, Qt will first treat the application's executable directory as the base directory for searching for plugins. For example if the application is in C:\Program Files\MyApp and has a style plugin, Qt will look in C:\Program Files\MyApp\styles.

On page "Qt for Windows - Deployment" there is written

The search path for Qt plugins is hard-coded into the QtCore library. By default, the plugins subdirectory of the Qt installation is the first plugin search path.

In fact, with the current implementation in Qt5.3, the second part is right, but it makes not much sense.

Of course, the solution is simple, qt.conf for example can help, but why the app should use a search path first, that is only relevant on a dev box and conflicts probably on another dev box where a different Qt version shares the same installation path like in 5.3.1 and 5.3.2?

By the way, the same problem with Qt5.3.2 MinGW, of course.