Same module with different versions in several places This the directory structure of my drupal 8 installation:

├── composer.json
├── composer.lock
├── drush
├── LICENSE
├── load.environment.php
├── phpunit.xml.dist
├── README.md
├── scripts
├── vendor
└── web
    ├── autoload.php
    ├── core
    ├── index.php
    ├── modules
    │   └── custom
    │       └── xyz (version 1.0)
    ├── profiles
    │   └── custom
    │       └── qwer
    │           └── modules
    │               └── custom
    │                   └── xyz (version 1.1)
    ├── robots.txt
    ├── sites
    │   └── example.com
    │       └── modules
    │           └── custom
    │               └── xyz (version 1.2)
    ├── themes
    ├── update.php
    └── web.config


Which version of xyz module "win" in this structure ? For example:
- A site installed with qwer profile (sites/example.com).
- A site installed without qwer profile  (sites/example.com).
- Another option ?

I would like to know the preference that Drupal has when it have the same module with different versions in several places
If each copy of the module in the directory structure is in fact a different version (the module's .info file must specify a version number), you can inspect the version listing either via Drush or on the modules listing (install) page. 

Version Listing from the Modules Listing page


Navigate to /admin/modules 
Find module "xyz" and expand the
description section to reveal which version is being
detected/loaded. 
Refer to the example screenshot below, where
Activity Tracker has been expanded.




Version Listing via Drush 


Run 'drush pm-list --no-core --status Enabled' to show a list of all modules other than those included with Drupal Core.
Scroll through the list to find your custom module and note the version number in the right column.
Refer to example screenshot below.




What if there are no version numbers, or they are all the same version?


Temporarily modify the version number in the info file.
Push the updated code to your server (if not a local copy of the site).
Flush Drupal Cache, rebuild the registry.
Follow the instructions above to detect which one is used.
Reset the version number and push the updated code to your server (if not a local copy of the site).


Drupal Multisite Note: 

If you are running Drupal Multisite, each site with the custom module enabled may be referencing it from a different path (depending on where the module was located at the time the site was being built). 


In this situation, check the versions on each site using the instructions above. 
Find the most updated version being used so that you can consolidate all the other sites to use the same version/instance.


Consolidating duplicate instances of the module

Since this is a custom module, be sure to check that the functionality provided between versions is in fact the same and that there is an upgrade path between them before consolidating. Sometimes, lesser experienced developers will copy a custom module and completely overhaul its functionality for use on a similar or different site without understanding best practices.


Backup your code and databases, just in case you need to rollback.
Remove older versions/unused copies, ideally keeping/moving your one copy of the module in /web/modules/custom/.
Push the updated codebase to your server.
Clear caches and rebuild the registry.
Run update.php or drush updatedb to ensure any update hooks for the module are applied.
Test the functionality the module provides on each site (for some custom modules, you may need to edit/resave the configuration settings for the module to properly function).
If all is working, it's recommended to create a new restore point backup; otherwise troubleshoot until you get it working or rollback.