前一陣子試著對 ScummVM 回報一項問題，雖然 DR 僅是回報問題而已，並非是最終找出問題肇因、並且修正問題的貢獻者。然而在過程中則發掘到一些似乎是前所未聞之事，相當罕見，好像是應該稍微記錄下來。
首先是不知何故，除了首頁以外，DR 始終沒有辦法檢視 ScummVM Issue Tracker 網站上任何進一步的功能頁面，也就無法查看問題清單，以及提交 Bug 報告。因為一律都會出現以下的純文字輸出訊息（時間日期則會異動）：
HTTP/1.1 NoneServer: gunicorn
Date: Sun, 29 Dec 2024 13:47:20 GMT
Connection: close
試過不同的網頁瀏覽器、私隱模式、不同作業系統、以及不同地區的 IP 位址（透過 VPN），都狀況依舊。唯獨發覺若是使用 curl 而非網頁瀏覽器，則能夠正常回傳頁面，並且也確認問題跟客戶端輸出的使用者代理字串無關，但實務上也很難真的僅僅用 curl 去操作網站。
由於這情形實在離奇，搞不清楚問題出在哪裡，DR 只能試著在 ScummVM 的 Discord 上反映自己遇到這樣的狀況。於是接著就是一連串的線上對話，不同人提出了不同的見解，而自己也必須說明已經做過了哪些嘗試。其中有人注意到瀏覽器擷圖中所顯示的中文介面（DR 一直以來都習慣於將 Mozilla Firefox 後來預設停用的選單列恢復啟用），也引起了一些詢問：
「你是在牆內嗎？」
「不，台灣沒有牆。」
……不過有留意到中文環境這點，也許是一定程度有助於釐清問題的方向。網站的維護者在查詢系統的錯誤日誌後，終於找到了罕見的真相──這恐怕是只有台灣繁中語系（zh_TW）的使用者才會遇到的錯誤，與上游套件錯誤地進行日期格式的轉換有關：
https://trac.edgewall.org/ticket/13482
對此情形，維護者先是在線上對話中提供了規避此錯誤的方法，再找時間徹底修正了問題。於是 DR 就終於可以真正地回報 ScummVM 的 Bug，而不是 ScummVM 網站的 Bug……那麼在終於提交 Bug 報告後，也順利地有開發者分析出問題點並提出修正。不過若檢視修正的差異細節（#6385），則出現了另一件奇事：可以看到在原先還未修改前的實作中，有一段程式碼結構使用了相當多階層的 if else 條件式。
雖然不敢說自己的程式設計經驗符合產業標準，不過倘若姑且就按照 DR 個人的認知，則 if else 最為常見通常是最多兩層，達到三層應該就會讓人很想要動手重構了──然而這裡的 if else 數算下來卻有八層之多，真的是徹底的金字塔結構，令人瞠目結舌。於是粗略地翻了一下歷史記錄，發現這段程式碼也大概存在有十年以上了。而最起初的項目貢獻者完全可以接受程式碼長這個模樣，似乎都未曾想要出手整理它，讓人覺得也是相當奇特。