ご意見ありがとうございます。
仕組みについて
WIKIWIKI の counter、online、popular は、PukiWiki に標準で搭載されている counter 系のプラグイン とは仕組みが異なり、Go 言語で独自に開発したカウンターサーバー で動作しています。
Amazon DynamoDB をストレージに使い、非同期で分散処理する仕組みによって、アクセスが殺到しても counter 数を壊さず、WIKI の基盤システムに負担をかけずに動かせるようになっています。
ただし、このカウンターサーバーは WIKI のページ情報そのものを持っていないため、存在していないページかどうかを判断することはできません。処理をシンプルに保つことで、大規模アクセスにも耐えられるようにしています。
公平性について
「popular の通算をリセットする機能（いわゆる counter リセット）」を導入すると、ユーザーが counter の数字を操作できることになり、各 WIKI の公平性や将来のアクセス数の目安としての信頼性が揺らぐ可能性があります。
また、rename によって counter の数字を 引き継ぐ ことも、人気ページのアクセス数を別のページへ移せてしまうため、望ましくないと考えています。
対応について
現時点で counter の数字をリセットできるようにする予定はありません。
その代わり、popular の仕組み自体を見直していて、非同期処理から半同期処理に切り替えることを検討しています。いまは非同期のリクエスト数がかなり多く、これを減らしたい狙いがあります。
仕組みとしては、WIKI の基盤システムから内部経路でカウンターサーバーの情報を取ってきて、ページの内容と一緒に出力するやり方です。最近では zrecent もこの半同期処理に移行しました。
この方法なら、WIKI の基盤で存在しないページを除外した集計が可能になります。ただし、集計の負荷がページ生成に乗ってくるため、その点は検討中です。
もしこの仕組みを導入する場合は、「負荷パネル」を見ながらユーザーの方に調整してもらう必要も出てくるかもしれません。
popular プラグインの廃止検討について
popular は、負荷の大きい集計系プラグインです。
現在では Google Analytics も利用できるため、必ずしも popular に依存する必要はありません。必要に応じて REST API を使って Google Analytics のデータを取得し、集計結果を定期的に WIKI ページとして生成する方法も可能です。
また、popular を必要以上に多用してランキングを作成するケースもあり、その結果ページ表示が重くなったり、期待通りの結果が得られないことがあります。こうした事情から、popular は 非同期処理として実装されてきました。
以上の背景を踏まえ、popular の提供方法を見直し、場合によっては廃止も視野に入れています。