TikZ fill not being drawn using named coordinates
This is a bug in how TikZ determines whether a node is a coordinate or not.
TikZ does something slightly different if a node is a coordinate to if it is not. If a node is not a coordinate then it has a definite size and the path should be broken on its boundary (so the path should stop at one side of the node and restart at the other). This introduces a move to the path which affects its ability to be filled. If a node is a coordinate, then it has zero size and so the path is not broken - there is no move - and this means that the path can be filled as expected.
What is happening here is that the test for a node being a coordinate is failing because that test does not take into account the name prefix setting. So TikZ doesn't think the node is a coordinate and is breaking the path (as the coordinate node has zero size, you don't see this break but it is there and that affects the filling).
The fix for the bug is straightforward, if you're happy with a little \makeatletter-\makeatother block in your preamble.
\makeatletter
\def\tikz@parse@node#1(#2){%
\pgfutil@in@.{#2}% Ok, flag this
\ifpgfutil@in@
\tikz@calc@anchor#2\tikz@stop%
\else%
\tikz@calc@anchor#2.center\tikz@stop% to be on the save side, in
% case iftikz@shapeborder is ignored...
% The next line is the fixed line with the addition of the `\tikz@pp@name`
\expandafter\ifx\csname pgf@sh@ns@\tikz@pp@name{#2}\endcsname\tikz@coordinate@text%
\else
\tikz@shapebordertrue%
\def\tikz@shapeborder@name{\tikz@pp@name{#2}}%
\fi%
\fi%
\edef\tikz@marshal{\noexpand#1{\noexpand\pgfqpoint{\the\pgf@x}{\the\pgf@y}}}%
\tikz@marshal%
}
\makeatother
This should be filed as a bug in TikZ/PGF. Adding this to your example ought to fix that particular issue.
(Note: I was working from Zarko's MWE as that was far simpler than yours, but I checked with yours and the same fix works. Just ensure that the above is after \usepackage{tikz} in your preamble.)
Your MWE has more problems:
- For your styles you use names which are already defined in TikZ. This is bad idea which can cause unexpected problems. Change this names, for example
edgetomyedgeetc. - use of calculation of coordinates. Your claim, that with use of coordinates you shorten the compilation time, seems not to be true. You only move calculation to coordinates.
- Use of
name prefix. On the first sight seems that you find bug, however, if you slightly change your code, your problem disappear.
As solution try to rearrange your MWE as is shown on following example:
\documentclass[tikz]{standalone}
\usepackage{xcolor}
\definecolor{red}{HTML}{DC291E}
\definecolor{blue}{HTML}{04588A}
\definecolor{orange}{HTML}{FA6B00}
\usepackage{tikz}
\usetikzlibrary{arrows.meta,
calc,
decorations.markings,decorations.pathmorphing,
external,
positioning}
\usepackage{siunitx}
\begin{document}
\begin{tikzpicture}
\pgfmathsetmacro{\SQ}{1/sqrt(20)}% <-- to for spare calculation time
\begin{scope}[name prefix = S1-]
\coordinate (bl-front) at (-4*\SQ, -2*\SQ + 3.0);
\coordinate (br-front) at (-4*\SQ+3,-2*\SQ + 3.0);
\coordinate (tl-front) at (-4*\SQ, -2*\SQ + 4.5);
\coordinate (tl-back) at (0, 4.4);
\end{scope}
% WHY YOU NO FILL? ... MOWED OUTSIDE OF "SCOPE", NOW FILL WORKS AS EXPECTED :-)
\draw[fill=gray] (3,3) node[right] {a}
-- (S1-tl-back) node[above] {b}
-- (S1-tl-front) node[left] {c}
-- (S1-br-front) node[below] {d}
-- cycle;
\end{tikzpicture}
\end{document}
In above MWE I introduce shorter coordinate names (for shorter code, this will not influence to work of MWE). I also use \pgfmathsetmacro' for calculatesqrt` only ones and than use result in coordinates.
Unfortunately I have some problem with LuaLaTeX installation, so I made test with pdfLateX engine, which show the same problem as you reported in your question. So, I conclude, that problem is independed of used TeX engine and proposed solution will work with LuaLaTeX