As a note, this rule seems to be explicitly stated on the git documentation page:
https://git-scm.com/docs/gitignore

If the pattern does not contain a slash /, Git treats it as a shell glob pattern and checks for a match against the pathname relative to the location of the .gitignore file (relative to the toplevel of the work tree if not from a .gitignore file).

Otherwise, Git treats the pattern as a shell glob suitable for consumption by fnmatch(3) with the FNM_PATHNAME flag: wildcards in the pattern will not match a / in the pathname. For example, "Documentation/*.html" matches "Documentation/git.html" but not "Documentation/ppc/ppc.html" or "tools/perf/Documentation/perf.html".

In this case, it "contains a /" and so will ignore ./path1/some_file_or_folder but not ./path2/path1/some_file_or_folder. I also found this exact same statement in the man gitignore pages on my git version:

git version 2.14.0
hub version 2.2.9

For example, "Documentation/*.html" matches "Documentation/git.html" but not "Documentation/ppc/ppc.html" or "tools/perf/Documentation/perf.html".

If i'm looking at it right, it seems like the ignore crate deliberately rejects this — there is a test asserting that src/*.rs should ignore src/grep/src/main.rs, which contradicts both the quoted text and git's actual behaviour:

% echo 'path1/*.rs' > .gitignore
% touch path1/foo.rs path2/path1/foo.rs
% git check-ignore -v path1/foo.rs; echo $?
.gitignore:1:path1/*.rs	path1/foo.rs
0
% git check-ignore -v path2/path1/foo.rs; echo $?
1

What causes this behaviour (and the issue with path1/*) is the implicit prepending of **/ to a rule even when it contains a /.