I think this is a renderer-side problem. For the code at the end, the left one is the screenshot and the right one is the exported PNG.
Here are some code/comment from pgfcorepatterns.code.tex;
% Creates a new colored pattern
%
% [#1] = optional list of variables.
% #2 = pattern name
% #3 = lower left of bounding box
% #4 = upper right of bounding box
% #5 = step vector
% #6 = pattern code
%
% Description:
%
% Declares a new colored pattern. Such patterns have a one or more
% fixed inherent colors. See the pdf-manual for more details on
% uncolored patterns.
%
% The parameters have the same effect as for uncolored patterns.
and code from pgflibrarypatterns.code.tex.
\pgfdeclarepatternformonly{north east lines}{\pgfqpoint{-1pt}{-1pt}}{\pgfqpoint{4pt}{4pt}}{\pgfqpoint{3pt}{3pt}}%
{
\pgfsetlinewidth{0.4pt}
\pgfpathmoveto{\pgfqpoint{0pt}{0pt}}
\pgfpathlineto{\pgfqpoint{3.1pt}{3.1pt}}
\pgfusepath{stroke}
}
So I think this is what happened
and what I did
\documentclass[tikz]{standalone}
\usepackage{tikz}\usetikzlibrary{patterns}
\pgfdeclarepatternformonly{south west lines}{\pgfqpoint{-0pt}{-0pt}}{\pgfqpoint{3pt}{3pt}}{\pgfqpoint{3pt}{3pt}}{
\pgfsetlinewidth{0.4pt}
\pgfpathmoveto{\pgfqpoint{0pt}{0pt}}
\pgfpathlineto{\pgfqpoint{3pt}{3pt}}
\pgfpathmoveto{\pgfqpoint{2.8pt}{-.2pt}}
\pgfpathlineto{\pgfqpoint{3.2pt}{.2pt}}
\pgfpathmoveto{\pgfqpoint{-.2pt}{2.8pt}}
\pgfpathlineto{\pgfqpoint{.2pt}{3.2pt}}
\pgfusepath{stroke}}
\begin{document}
\begin{tikzpicture}
\fill[pattern=north east lines](0,1)rectangle(1,0);
\fill[pattern=south west lines](0,1)rectangle(-1,0);
\end{tikzpicture}
\begin{tikzpicture}[line width=.4cm]
\begin{scope}[opacity=.25]
\draw[thin](1,2)rectangle(2,1)(1.5,1)node[below]{de facto bounding box};
\draw[thin](0,3)rectangle(3,0)(1.5,0)node[below]{tessellating box};
\draw[thin](-1,4)rectangle(4,-1)(1.5,-1)node[below]{bounding box};
\draw[opacity=0](-1,4)rectangle(4,-1);
\draw(0,0)--(3.1,3.1);
\end{scope}
\clip(1,2)rectangle(2,1);
\draw(0,0)--(3,3);
\end{tikzpicture}
\begin{tikzpicture}[line width=.4cm]
\begin{scope}[opacity=.25]
\draw[thin](0,3)rectangle(3,0)(1.5,0)node[below]{bounding box = tessellating box};
\draw(0,0)--(3,3)(-.2,2.8)--(.2,3.2)(2.8,-.2)--(3.2,.2);
\end{scope}
\clip(0,3)rectangle(3,0);
\draw(0,0)--(3,3)(-.2,2.8)--(.2,3.2)(2.8,-.2)--(3.2,.2);
\end{tikzpicture}
\end{document}
south east version
For your convenience, here is a south east version
\pgfdeclarepatternformonly{south east lines}{\pgfqpoint{-0pt}{-0pt}}{\pgfqpoint{3pt}{3pt}}{\pgfqpoint{3pt}{3pt}}{
\pgfsetlinewidth{0.4pt}
\pgfpathmoveto{\pgfqpoint{0pt}{3pt}}
\pgfpathlineto{\pgfqpoint{3pt}{0pt}}
\pgfpathmoveto{\pgfqpoint{.2pt}{-.2pt}}
\pgfpathlineto{\pgfqpoint{-.2pt}{.2pt}}
\pgfpathmoveto{\pgfqpoint{3.2pt}{2.8pt}}
\pgfpathlineto{\pgfqpoint{2.8pt}{3.2pt}}
\pgfusepath{stroke}}
I think the confusion comes from the fact that TikZ works with referrals not objects. When certain node name a is mentioned. It usually assumes that the user probably means its center coordinate. Or in case of drawing things between two things if one of them is a node then it computes the point on its border magically so the user doesn't notice.
But all of this is done internally. And nothing is related to nodes or else. A node has a name that you can refer to and predefined places where it understands.
None of these are stored. They are simply checked for existence or just executed. In other words, if you write shape=duck, then it doesn't go through all possible shape names, it simply does an existence check of the sort (I'm using nonsense names for the actual macros)
\pgfutil@ifdefined\pgf@Shape@#1@...{<if it exists use>}{<if not err>}
Anchors are the same deal, if you say anchor=heel, it asks for that name via some \pgf@sh@#1@anchor@#2 and so on.
Now where do these come from? They are defined at the shape declaration via \savedanchor and \anchor and so on.
So they are there and meticulously arranged so that when you refer to it everything from the textbox width height to shape path is painfully hand coded. That's why it is a very tedious job to define new shapes. And when you refer to them they are arranged in such a way that the anchor position is written (globally!) inside the length registers \pgf@<x,y>
Anyway long story short, when you refer to a node anchor actually there is a pretty involved procedure to get a coordinate out of it.
Furthermore, there is a difference between a coordinate which is \pgf@<x,y> and a coordinate type node which is \coordinate.
Finally, when you refer to a node, TikZ try to help you by assuming that you meant its center anchor so that you can save some keystrokes but occasioanlly you need to make a finer surgery such as distance measurements.
You cannot get away with referral names. You need actual coordinates (again not \coordinates). As Mark Wibrow commented, you have to somehow understand the context and that is done via \pgf@process to answer such questions: is it a literal coordinate(1,1), is it a node name, is it a node anchor etc. Then you can use the resulting \pgf@<x,y> registers.
Then you can do whatever you want with them. Your example let syntax also does an amazing job to simplify this but it is still doing what you have described. Actually your question is basically why TikZ exists on top of PGF. It is a very well designed front end to a very verbose but powerful syntax of PGF.
Best Answer
There is a paragraph indentation. The white space is gone with
\noindent: