When a shared object built with Intel10_64lp (etc.) is loaded with RTLD_LOCAL, it drops as "Intel MKL FATAL ERROR: Cannot load libmkl_avx2.so or libmkl_def.so.". There is no problem if you load it with static link or RTLD_GLOBAL. However, loading the Python module has to be rewritten globally with sys.setdlopenflags, so it seems to be difficult in practice.
https://gitlab.kitware.com/cmake/cmake/issues/20491#note_719552
BLA_VENDOR = Intel10_64lp (etc.) will automatically take precedence in CMake 3.13 and above. You can use BLA_VENDOR = Intel10_64_dyn in CMake 3.17 (which will solve it), but you have to specify it explicitly. I received a reply saying that I will not change the priority, so it seems that I have to be careful when find_package (BLAS) for a shared object.
demo: https://github.com/cielavenir/cmake_intel_blas
[C] load blas user statically
ans=[ [ 2.10e+01, 3.36e+02, 7.08e+01]; [ -6.40e+01, 5.14e+02, 9.50e+01]; [ 2.10e+02, 3.10e+01, 4.75e+01] ]
[C] load lapack user dynamically
ans=[ [ 2.10e+01, 3.36e+02, 7.08e+01]; [ -6.40e+01, 5.14e+02, 9.50e+01]; [ 2.10e+02, 3.10e+01, 4.75e+01] ]
[Python] load blas user [cdll]
Intel MKL FATAL ERROR: Cannot load libmkl_avx2.so or libmkl_def.so.
[Python] load blas user [cdll] with modifying dlopenflags
ans=[ [ 2.10e+01, 3.36e+02, 7.08e+01]; [ -6.40e+01, 5.14e+02, 9.50e+01]; [ 2.10e+02, 3.10e+01, 4.75e+01] ]
[Python] load blas user [module]
Intel MKL FATAL ERROR: Cannot load libmkl_avx2.so or libmkl_def.so.
[Python] load blas user [module] with modifying dlopenflags
ans=[ [ 2.10e+01, 3.36e+02, 7.08e+01]; [ -6.40e+01, 5.14e+02, 9.50e+01]; [ 2.10e+02, 3.10e+01, 4.75e+01] ]
Well, that's openrave. There is find_package (LAPACK), but it has the same phenomenon.