I don't think bug #15338 is related.  However this is a duplicate of bug #10708.

Below is a stripped-down version of a much more complicated makefile.

Several %.r files are targets. Each %.r goes into one directory called
$(RES_DIR), and depends on a %.exe of the same name in another
directory, called $(EXE_DIR).

The %.exe are intermediate targets. Normally they are generated by
compiling, and have a pattern as a prerequisite too, but for these
purposes, no prerequisite is necessary, and we'll just create a shell
script executable.

The problem: If the %.exe files are explicitly listed as coming from
./ (the working directory), the ./ is stripped from the targets and
prerequisites.

That is, if $(EXE_DIR) is . then $(EXE_DIR)/ is not left intact in
$@ and $<.

This occurs in three contexts in which the ./%.exe pattern is used
below: When the ./%.exe is a target, when the ./%.exe is a
prerequisite, and when the pattern is used to declare the %.exe
targets as immediate:

# make
$(EXES) = ./a.exe ./b.exe                      GOOD
echo "echo I hope . is in your path" > a.exe   Should be ./a.exe
chmod a+x a.exe                                Should be ./a.exe
a.exe                                          Should be ./a.exe
I hope . is in your path
$(EXES) = ./a.exe ./b.exe                      GOOD
echo "echo I hope . is in your path" > b.exe   Should be ./b.exe
chmod a+x b.exe                                Should be ./b.exe
b.exe                                          Should be ./b.exe
I hope . is in your path
rm a.exe b.exe                                 Consistent

If . is not in your PATH, then this error occurs:

# make
$(EXES) = ./a.exe ./b.exe
echo "echo I hope . is in your path" > a.exe
chmod a+x a.exe
a.exe                                          Should be ./a.exe - FATAL
make: a.exe: Command not found
make: * [results/a.r] Error 127
rm a.exe

The problem is the same whether ordinary rules, pattern rules, or
static rules are used.

There are workarounds, such as adding . to your PATH (insecure!),
explictly using ./$< instead of $< (won't work if EXE_DIR is changed
to an absolute path), etc. But none of these should be necessary,
because the explicit ./%.exe pattern should have remained intact.

For the purposes of comparing whether two targets or prerequisites
are the same name, leading ./'s should be ignored. But leading ./'s
should be kept intact in automatic variable expansions such as $<
and $@.

(Bugs 10708 and 15338 are the same thing. This is just another example
showing how it can fatally ruin a project -- a make "project", that is.)