W pierwszym podejściu […] łatwiej rozwijać program z uwagi na loose-coupling
W drugim podejściu […] łatwiej "zobrazować" całość działania programu, ale ciężej go rozwijać przez tight-coupling
Mówisz? Dosyć trudno mi sobie wyobrazić parser, w którym w ogóle da się i jest sens osiągać taką niezależność, że generowanie błędów jest fundamentalnie niezależne od samego efektu działania parsera… Myślisz, że jest w jakimkolwiek stopniu realistycznym scenariusz, w którym wymieniasz raportowanie błędów, nie ruszając jednocześnie części modyfikującej plik; albo vice versa?
Istotnie łatwiej, ale wciąż nietrywialnie, jest mi przyjąć, że jednocześnie łatwo jest zrozumieć, co działa, jak działa, i czemu tak (zakładam, że właśnie to miałeś na myśli, pisząc o „łatwości zobrazowania”); oraz „wyjaśnienie” rzeczy czyni wyjaśnianą rzecz bardziej oporną na modyfikację.
No ale, przyjmując za dobrą monetę ww. wnioski, to pierwsze podejście wydaje się mieć praktycznie same zalety i bardzo mało wad. Mówisz, że przelecenie dwa razy to nie problem (i ruszanie tego to by była „mikrooptymalizacja” — IMO to brzmi bardziej, jak optymalizacja architektoniczna, czyli właściwie przeciwieństwo mikrooptymalizacji, ale miałem przyjmować Twoje stanowisko na wiarę…); a po co komu łatwość w zrozumieniu czegoś, skoro nie będzie mógł tego łatwo ruszyć tak czy owak.
Zatem jeśli faktycznie jest tak, jak piszesz, to nie widzę nawet powodu do zastanawiania się — bierz pierwszą opcję i fajrant. Jedyna wada (dwukrotny przejazd po pliku) nie jest wadą, a jedyna zaleta (łatwe zrozumienie nie tylko nieidące w parze z jakimkolwiek zyskiem praktycznym, ale wręcz powiązane z faktycznymi problemami) nie jest zaletą.