This is the only scenario where it differs from clojure-find-ns after this PR.

Is there any particular reason for this change?

AFAIU It's debatable what is the correct behaviour here.
clojure-mode finds the closest ns above point and falls back to finding the closest ns below point.

1. My understanding is that clojure-mode finding the closest ns is more of a result of an implementation detail rather than desired behaviour.

2. Also I haven't figured out yet how to find all occurrences or do a reverse search with tree-sitter queries.

I recall in the beginningclojure-mode was just looking for ans form in the beginning of the file, but then we changed it, as per the Clojure specification the currentns was supposed to be whatever ns is closest above the form in question. I don't recall doing a search below as well, but perhaps there was some reason for this.

Anyways, if by first you mean "closest above" (and so it seems looking at the tests), I think that's fine.

Right now it's first from the beginning of file. (point is not used at all).
This is the behaviour before the PR as well. I haven't updated it as it would require more complicated tree-sitter queries.

The below test is matching the 3rd ns only because the first 2 are invalid not because of the point.

If clojure-mode behaviour is ideal I would prefer to create a new issue and handle it in a separate PR.(Need more tree-sitter knowledge to handle the queries there.)

That'd be fine by me.

In general that has never been super important for me (to do this by the letter), as usually source files have only the leadingns form. But clearly it was a problem for some users ofclojure-mode. :D

@p4v4n If you'd like to chat about tree-sitter-clojure, there is a gitter / matrix channel.

See the bottom ofthis for links if interested.

Might be better to preserve the copyright attribution of the original code.

Will add them back.