結局どうするのか

今回の騒動を引き起こしたそもそものきっかけであるwalkerplus(85745)をどうするかという話です。
アイテム: walkerplus - データベース: AutoPagerize - wedata
トマ村さん案

//main/section/node()[contains(.,'start ニュース本文')]/following-sibling::*[following-sibling::node()[contains(.,'end ニュース本文')]]

更新案A

//main//ul[.//img]|descendant::*[./figure/a][1]

更新案B

descendant::*[./figure/a][1]|//a[@rel="next" or @rel="prev"]/ancestor::div[./following-sibling::div][1]/preceding-sibling::div[1]//ul

更新案C（現状）

descendant::*[./figure/a][1]|descendant::*[count(./preceding-sibling::div)>1 and count(./following-sibling::div)>1][1][count(./*)>1 or ./ul]

テキストノードを使いたくないのでトマ村さん案を更新したのですがGrieverさんの評価は思った以上に高いようです。たしかに階層を順にたどって考えればよいという意味ではシンプルなコードだと言えます。

いくつか更新案を考えたのですが、Aは先のエントリで否定されてしまいました。

またドキュメントの出現順に要素をチェックするので目的の ul が見つかったのにその中の深い階層まで img を探しに行くのは非効率に感じます（プログラマの考え方です）
Griverさんへの返信その２ - 1300

これを踏まえてひねり出したのがBとCです。

BはnextLinkのある階層からancestorで祖先ノードへ逆流し、複数のdivが存在する直近の階層を探しています。Cは同一階層にあるprecedingとfollowingのdivを数え、同一階層に５以上のノードが存在する３番目を確保しています。

どれがよいと判断するかは人によって異なるはずですからこのまま更新がなければ現状を維持します。いい勉強になりました。

やはり気になるので少し妥協します。article_listを新規に分けました。

descendant::*[contains(@class,"date")][1]/../following-sibling::div[position()<3]

//li[./div/*[contains(@class,"date")]]