I thought that the branch source plugins (GitHub, Gitea, and possibly Bitbucket) provide a technique to avoid the copy of the full repository to retrieve the Jenkinsfile.
However, if you're trying to avoid cloning the shared library repository, I'm not sure what that will gain, since the shared library repository needs to provide multiple files, not just the single Jenkinsfile.
I think it is wise to keep the size of the shared library repository small, containing only shared library components. You don't want unrelated changes causing concern for the users of the shared library.
Jenkins checkout the Jenkinsfile first and then the scm inside the jenkins checkout. If you can, try to enable the Lightweight checkout on the jenkinsfile checkout.
Side note, I for one make a repos for the jenkins file that is not the same as the code repos, so my server and build setup evolve at different pace as the code and I can build old version into a recent configuration (jenkins updated and jenkinsfile needed to be modified for a while). I did more enjoy doing it this way then having my Jenkins file static into a revision of the source repos. I can also try different Jenkinsfile with the same source code Jenkinsfile checkout use build parameter.
Side note #2: I also use mercurial with sub repos, so my jenkinsfile pull subrepos for the shared scripts/lib/exe that I use during the build process, this work like a charm.