Question: How should comment blocks be addressed in the HM protocol? Should they get their own block ID namespace, reuse the document block ID scheme, or something new?

Why now: Point #2 in What I want for the commenting experience explicitly requests block-level comment IDs and ranges. This is a protocol-level question that must be answered before implementation.

Dependencies: HM protocol spec, comment storage model

Priority: High — blocks opportunity #2 in the backlog

Question: What does "full-window discussions" look like in the best products? How do Slack threads, GitHub PR discussions, Linear comments, and Notion comments handle the split between document/content and discussion?

Why now: Point #1 is the highest-impact, lowest-effort opportunity. The design can be informed by existing patterns.

Priority: High — directly enables the #1 ranked opportunity

Question: How do the best mobile apps (Linear mobile, Slack, Discord, Apple Notes) handle inline text editing with formatting? What makes their comment box feel responsive?

Why now: Points #3 and #4 are mobile-specific. The editor lag and drawer jankiness need to be benchmarked against best-in-class.

Priority: Medium — complements the mobile formatting toolbar project

Question: Now that the redirect is eliminated, what edge cases remain? Are there any sites/configs where commenting still breaks?

Why now: The Killing Web Redirect project is completed. Need a systematic audit of remaining edge cases.

Priority: Medium — monitoring/quality

Question: The current discussions panel flattens threads into a tree. What's the right threading model for HM? Reddit-style unlimited nesting? Linear-style flat replies? GitHub-style side-by-side?

Why now: The Discussions Panel Is Confusing document and point #1 (full-window) suggest the current model isn't working.

Priority: Medium — informs the full-window design