Fortschrittsbalken in Beamer (Begrenzung durch Folienanzahl)

Wie @huibub bereits in seinen Kommentaren richtig bemerkt hat, darf bei TeX das Ergebnis einer arithmetischen Operation maximal \maxdimen groß sein. \maxdimen ist 16383.99999pt. Dieser Wert wird bei dir bereits auf Frame 45 (und nicht erst auf Frame 90, wie in der Fragestellung behauptet) überschritten. Eine einfache Lösung wäre nun, am Anfang nicht mit der Hälfe der Papierbreite zu rechnen und diese dann am Ende per \progressbar@tempdim=2\progressbar@tempdim wieder auf die ganze Papierbreite zu erhöhen, sondern mit einem wesentlich kleineren Anteil zu arbeiten.

Zusätzlich wäre theoretisch in der Tat zu empfehlen, erst durch die Gesamtzahl der Frames zu dividieren und dann mit der aktuellen Framenummer zu multiplizieren. Leider hat das am Ende dann keine Auswirkungen, weil, wie @huibub ebenfalls in seinen Kommentaren richtig bemerkt, \inserttotalframenumber im ersten LaTeX-Lauf natürlich noch nicht die Gesamtzahl der Frames liefert.

Das Problem mit dem zu kleinen \inserttotalframenumber kann man einfach lösen, indem man testet, ob \inserttotalframenumber größer oder gleich \value{framenumber} ist, was es ja immer sein sollte. Anderenfalls ist die Progressbar ohnehin ungültig und braucht überhaupt nicht mehr (oder alternativ nur mit voller Länge) gezeichnet zu werden. An dieser Stelle sei auch darauf hingewiesen, dass \insertframenumber nicht unbedingt der Weisheit letzter Schluss für die Verwendung in einer Berechnung ist. Ich werde daher stattdessen direkt den Frame-Zähler framenumber verwenden. Kombiniert man das nun mit dem Vertauschen der Operationen ist sichergestellt, dass kein zu großes Zwischen- oder Endergebnis vorkommt und man kann sich die Halbierung aus dem Originalcode sogar ganz sparen.

\documentclass{beamer}
\usepackage{tikz}
\definecolor{pbbg}{RGB}{0,122,59}% filling color for the progress bar
\definecolor{pbfill}{RGB}{0,122,59}% background color for the progress bar

\makeatletter
\def\progressbar@progressbar{} % the progress bar
\newdimen\progressbar@pbht %progressbar height
\newdimen\progressbar@pbwd %progressbar width
\newdimen\progressbar@tmpdim % auxiliary dimension
\progressbar@pbwd=\paperwidth
\progressbar@pbht=0.5ex
% the progress bar
\def\progressbar@progressbar{%
  % Die Progressbar ergibt nur Sinn, wenn \inserttotalframenumber > \value{framenumber} ist
  \expandafter\ifnum \value{framenumber}>\number\inserttotalframenumber\relax\else
    \progressbar@tmpdim=\progressbar@pbwd
    \divide\progressbar@tmpdim by \number\inserttotalframenumber\relax
    \multiply\progressbar@tmpdim by \value{framenumber}
    \begin{tikzpicture}[rounded corners=1.5pt,very thin]
      \shade[top color=pbbg!20,bottom color=pbbg!20,middle color=pbbg!50]
        (0pt, 0pt) rectangle ++ (\progressbar@pbwd, \progressbar@pbht);

      \shade[draw=pbfill,top color=pbfill!50,bottom color=pbfill!50,middle color=pbfill] %
        (0pt, 0pt) rectangle ++ (\progressbar@tmpdim, \progressbar@pbht);
      \draw[color=normal text.fg!50]
        (0pt, 0pt) rectangle (\progressbar@pbwd, \progressbar@pbht)
        node[pos=0.5,color=normal text.fg] {\textnormal{%
        }%
      };
    \end{tikzpicture}%
  \fi
}
\addtobeamertemplate{footline}
{%
  \begin{beamercolorbox}[wd=\paperwidth,ht=2.0ex,center,dp=0ex]{white}%
    \progressbar@progressbar%
  \end{beamercolorbox}%
}
\makeatother    
\begin{document}
\foreach \x in {1,2,...,90} {\begin{frame}[label=test\x]{My frame}
    Test \x
\end{frame}}
\end{document}

Es sei darauf hingewiesen dass es auch einen Nachteil dieser Lösung gibt. Sobald sich die Anzahl der Frames der Breite der Frames in sp annähert, wird die Rechenungenauigkeit von TeX so groß, dass der Fortschrittbalken durch die Rundung zu kurz wird und letztlich auf 0 stehen bleibt. Das dürfte bei Präsentationen aber eine eher theoretische Beschränkung sein, da ich schon Frame-Zahlen im Bereich der in der Frage fälschlich angegebenen Grenze von 90 für eher unüblich hoch halte. Präsentationen mit mehreren tausend Frames dürften in freier Wildbahn kaum vorkommen.

Übrigens ist auch @huibub's Frage berechtigt, warum man die Berechnung nicht gleich mit pgf selbst durchführt. Ich habe nur gerade keine Zeit, mich mit einer entsprechenden Lösung zu beschäftigen.

Mit dem ebenfalls von @huibub gemeldeten Problem der destination with the same identifier habe ich mich ebenfalls befasst. Man kann einfach nicht auf jedem Frame Option label mit demselben Wert verwenden. Das ist schlicht sinnloser Unfug. Der Informationsgehalt ist dann nicht besser als bei Weglassen des Labels. Ich habe stattdessen ein eigentlich ebenfalls sinnloses, eindeutiges Label gesetzt – sinnlos deshalb, weil man eigentlich kein Label mit der Labelnummer im Namen braucht, um die Labelnummer zu bestimmen. :-O