Ein wenig komplexer ist das schon. Vergiss yaourt und frag einfach nicht danach. Die Frage, die Du eigentlich stellst, betrifft nur pacman. Und das verhält sich dann wie ein normales Abhängigkeitsproblem. Im schlimmsten Fall - Pech gehabt und nachfrickeln.
Klingt vielleicht jetzt ein wenig überheblich oder abgehoben - ist aber so. yaourt oder clyde oder was auch immer machen eigentlich nur eins. Sie vereinfachen den Prozess der Erstellung der Pakete aus Quelltext und sind reine wrapper um pacman respektive nutzen die Libraries von pacman.
Warum ich geschrieben habe - Pech gehabt, nachfrickeln: Jedes Paketmanagement ist nur so gut wie das schwächste Glied. Und das sind im Zweifel die AUR-Pakete. Davon ausgehend, dass die Abhängigkeiten korrekt verwaltet werden - stelle Dir bitte den Fall vor, in dem runtime-dependencies nicht ordnungsgemäß im Paket vermerkt sind. In diesem Fall bist Du einfach nur Nase. Spasseshalber kannst Du diesen Fall einfach nachstellen. Such Dir ein Paket aus, was seltene Abhängigkeiten hat. Stelle sicher, dass diese Abhängigkeiten (Build und Runtime) installiert sind. Modifiziere das zu bauende Paket dadurch, dass Du ein oder zwei Runtimes (im PKGBUILD) einfach löschst. Baue und installiere. Dann lösche die benötigte Abhängigkeit.
Dieses Konstrukt ist nicht mal weit hergeholt. In diesem Fall hast Du einen Bruch im System, der eventuell nicht sofort auffällt und deshalb nur sehr schwer zu reproduzieren sein dürfte. Darin sehe ich die wirkliche Gefahr bei Paketen aus dem AUR. Die Pakete aus den offizielle Repositories können diese Krankheit zwar auch haben, aber die Chance, dass so was passiert, ist wesentlich geringer, da die Massnahmen zur Qualitätssicherung bei Arch eigentlich recht gut greifen. Nur halt bei Paketen aus dem AUR nicht. Deshalb ist auch der Weg nach Community relativ lang und steinig.
Das sagt jetzt auf keinen Fall aus, dass die Pakete im AUR von schlechter Qualität wären. Jeder der Pakete da reinstellt, macht das so gut er kann. Auch im Aur gibt es Rückmeldungen. Nur die Gefahr, sich die eine oder andere Inkonsistenz ins System zu holen, ist größer als bei den offiziellen Paketen.
Das war jetzt der beschriebene worst case. Was viel häufiger der Fall sein dürfte: Durch nicht oder nicht ganz richtige Versionsbegrenzungen könnte durch das ein oder andere Paket die ein oder andere Schnittstelle nicht ganz passen, was auch ganz witzige Effekte hervorrufen kann. Und dann wirds echt haarig, das zu debuggen. Das hab ich durch und das hat auch keinen Spass gemacht. Das ist aber alles kein Problem von pacman oder yaourt - die können in den beschriebenen Fällen rein gar nichts zu den Problemen dazu. Das ist dann das gute alte Prinzip Shit in - Shit out. Passiert halt schon mal, ist aber ein Problem in den Quellen.
EDIT: Das ist auch in debian möglich - da wird es nur dadurch verhindert, dass alle Pakete ihren Weg gehen über experimental oder sid als Einstieg gehen. Wenn die dann als stable deklariert sind, dann kann man davon ausgehen, dass keine oder nur sehr wenige grobe Klopfer in den Paketen verblieben sind. Nimmst Du nur einen dieser Filter weg, dann steigt halt die Zahl der Fehler im Endprodukt. Viele grundlegende Fehler kommen auch in debian erst gar nicht an, da die zuerst in den richtig blutigen Quelltext-Distries aufschlagen dürften. Was dann in experimental aufschlägt, ist aber (oder kann) immer noch in einem Zustand sein, der den Status experimental mehr als rechtfertigt. Genau aus diesem Grund wird auch bei Arch vor den unstable-Repos und testing gewarnt. Die sind das wirklich. Die Fehler schlagen da ungefiltert durch und sollen das auch. Der upstream hat in solchen Szenarien alle Hände voll zu tun und freut sich wahrscheinlich über die Anzahl an pre alpha Testern. Die KDE-Entwicklung von 4.6 recht hautnah mitzuerleben hat auf jeden Fall Spass gemacht. Arbeiten hätte ich damit aber nicht wollen.
