While we have broadened the scope of this topic from “admin_level for four Midwestern/Plains states” to a more purposeful future of how we endeavor to update our documentation, the latter does naturally follow from the former, especially as Henning updates / synchronizes the table(s).
The tables aren’t exactly “duplicated,” although they can be or seem redundant for certain purposes. The admin_level table does not explicitly specify border_type data (for 47 states where this is less critical compared to how OSM tags to be relevant), whereas the Boundaries table does do this more explicitly for states where these data are found and more relevant (especially Maine, New Hampshire and Vermont). Given the different font that these tags are expressed in at the top of the table, this (more precise syntax) is at least somewhat visually clear, though perhaps its intentions could be made more explicit in the text of the Boundaries wiki.
Moreover, Minh recalls here that his initial creation of Boundaries was as a more “simple, digestible guide” that avoids edge cases and “streamlines towards simplicity” (an admirable goal, to be sure). But as our knowledge of specificity in more and more states has deepened, and each table gets updated with this knowledge (thank you, Henning, for your updates / synchronizing of the Boundaries table!) Minh says that this complexity drifts away from simplicity (and it does, especially as the two tables converge towards staying roughly or exactly sync’d with each other, including the fact that the Boundaries table has additional border_type data).
Regarding a “how-to guide,” I’m not sure how best to proceed, and if our Boundaries wiki getting updated over the years has spoiled that somehow, I apologize for any part I might have played in that (unintentionally, as I only wished to update, not radically change the original intention) and listen as to how that may be remedied. Indeed, it may be a best approach is for a third wiki, as I’m not sure how Minh might intend for the Boundaries wiki to best “return to its roots.”
Wiki can and do straddle not-always-clear purposes of whether they “seek to shape the database” (prescriptive) versus “describing it” (descriptive), and we do characterize these two wiki as being skewed towards different ends of this spectrum (admin_level as more prescriptive, Boundaries as less prescriptive, more descriptive). If there are additional purposes for which wiki should be written (for example, as a how-to guide for less-experienced mappers), it does seem to me this should be a goal “started anew” and crafted specifically for that purpose.