Perpendicular lines from the same point to the same line are different

Those inaccuracies are one of the reasons why Alain Matthes created the tkz-euclide package, which doesn't have the same problems. If you work with these kinds of geometric drawings a lot, it's definitely worth getting to know the package.

\documentclass[border=12pt]{standalone}

\usepackage{tkz-euclide}
\usetkzobj{all}

\begin{document}    
    \begin{tikzpicture}
        % Define points
        \tkzDefPoint(0,10){A}
        \tkzDefPoint(12,9){B}
        \tkzDefPoint(10,4){C}

        % Calculate projection, don't update bounding box
        \begin{pgfinterruptboundingbox}
            \tkzDefPointBy[projection=onto A--C](B) \tkzGetPoint{E}
            \tkzDefPointBy[projection=onto C--A](B) \tkzGetPoint{F}   
        \end{pgfinterruptboundingbox}

        % Draw objects
        \tkzDrawPolygon(A,B,C)
        \tkzDrawSegment[blue](B,E)
        \tkzDrawSegment[red](B,F)
        \tkzDrawPoints(A,B,C, E, F)

        % Labels
        \tkzLabelPoint[anchor=30](E){E}
        \tkzLabelPoint[below](F){F}
        \tkzLabelPoint[left](A){A}
        \tkzLabelPoint[above right](B){B}
        \tkzLabelPoint[below right](C){C}

    \end{tikzpicture}
\end{document}

If there is no other bug is lying in some corner, that's typical TeX precision failing. The calc syntax actually rotates things around and gets the angles accordingly in a fashion that is not-so-relevant.

But because the trigonometry functions work with look up tables the inbetween behavior can lead the inaccuracies. For example for the C coordinate try the x-coord values 9.65,9.8,10, and 10.15 and you will see the pattern.

If you drew the same figure in Metapost, (defining the projection from two different directions in the same way as you did in TikZ), you would also find that the points are not identical. However the error is much smaller - typically less than 0.01 mm, which is usually too small to be noticed.

prologues := 3;
outputtemplate := "%j%c.eps";

beginfig(1);
u := 1cm;
pair A, B, C, E, F;
A = (0,10u);
B = (12u,9u);
C = (10u,4u);

% define F back-to-front...
E = whatever[A,C]; B-E = whatever * (A-C) rotated 90;
F = whatever[C,A]; B-F = whatever * (A-C) rotated 90;

show E, F, abs(E-F);

draw A--B--C--cycle;
draw B--E withcolor blue;
draw B--F withcolor red;

label.top("A", A);
label.top("B", B);
label.bot("C", C);
label.llft("E", E) withcolor red;
label.lrt ("F", F) withcolor blue;
endfig;
end.

With the default number system the show command produces this:

>> (262.62154,125.88998)
>> (262.6223,125.89125)
>> 0.00148

So E does not equal F but it's pretty close. The units are points 72 = 1in, so the distance is 0.00148 points, which is about 0.5 µm, which is pretty hard to see.

If you use -numbersystem=double you get:

>> (262.62152205882353,125.89158676470589)
>> (262.62152205882353,125.89158676470583)
>> 5.6843418860808015e-14 

which is rather closer but still not exactly the same. But with -numbersystem=decimal you get:

>> (262.6215220588235294117647058823529,125.8915867647058823529411764705883)
>> (262.6215220588235294117647058823529,125.8915867647058823529411764705883)
>> 0 

In all three cases the output looks exactly the same to me.