It seem that the issue was 2-fold,
When doing this on a windows share-point, and sourcing it, find returns very slowly, the first time. But much faster the second time. Somehow there must be some kind of buffering/cache'ing going on. So the user thinks that the command failed or blocked. This is not the case when executing. As sourcing is run in the current shell, globstar probably need to be enabled. Running it as a script seem to not have this issue and also seem to be independent of the globstar setting.
The result of above, is that somehow the character set also confused find when running as a script vs. sourced. Running sourced would use the locally set character set of the terminal which is correct, while scripted, would use that of the default/OS, AFAICT. (I work in 3 different languages.)
What I did not know or tell in OP, is that I was using another language characters (containing umlauts) in the /*Some/*Place/ part. I didn't think it would matter, but it caused the command to fail. As it secretly was searching for the 2-byte UTF-8 characters, while correctly displaying only one.
I'm not completely sure what is going on under the bash hood here, but fiddling with the character sets, and patienly wait for the results, I got it to work as expected. Feel free to post a better or more clear answer.