The factors that determine which library is selected when multiple match an
#include directive are documented here:
Note this part:
The "location priority" is determined as follows (in order of highest to lowest priority):
... (irrelevant factors)
- The library is under the
libraries subfolder of the IDE's sketchbook or Arduino CLI's user directory
- The library is bundled with the board platform/core (
So if all the other factors are the same, then your library in
D:\Users\Damir\Documents\Arduino\libraries will have higher "Location Priority" than the one in
C:\Users\Damir\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.8.3\libraries and be picked.
This means there is some other more important difference between the two libraries that is causing the other to get priority. We know it's not "Folder Name Priority" because both libraries have the same folder name. So it must be "Architecture Matching". You can check by opening the metadata file in a text editor:
But we also might investigate exactly why you want to do this thing. It is very unusual to install the SPI library under your sketchbook. This can cause problems because the SPI library contains architecture-specific code. So, for example, the SPI library written for the AVR architecture of the Uno is completely different from the one written for the ESP8266. This is the reason the SPI library is bundled with the boards platform.
The platform bundled libraries are only accessible when compiling for a board of that platform. So this means that the IDE will automagically use the right version of the library for each board. Ideally, the fact that completely different libraries are used from one board to another isn't noticeable to the user because all the versions of the library use a standardized API, so the code that uses that API will work for every board. But the sketchbook installed libraries are always accessible. So when you install a library like SPI there, you might end up in a situation where a library is being used for a board it's not written for, which could cause very confusing results. In practice, "Architecture Matching" will usually ensure that the right library is picked, but that's not guaranteed.
The dependency resolution system works exactly the same on every operating system. So there must be some other factor in play here.