Resource template with a literal `?` is listed but can never be read

Finding: In a reporter's FastMCP dev build (4.1.1.dev2+e2fcc412, MCP 2.0.0, Python 3.12.3, macOS arm64), a resource template whose URI contains literal query text, such as search://items?q={q}, is reported to register without error and appear in resources/templates/list, yet reading a matching URI such as search://items?q=abc fails with Resource not found. Source: https://github.com/PrefectHQ/fastmcp/issues/5660. Reported behavior: The reporter supplies a minimal example using @mcp.resource("search://items?q={q}") and an in-memory Client. Listing templates returns the expected template string, but read_resource raises an MCPError with the not-found message shown above. The reporter expects the read to return q=abc, since the template is plain RFC 6570 simple expansion following literal text (issue #5660). Scope as reported: The same failure is said to occur through mount() and create_proxy(). The reporter calls the proxy case the most painful: a backend built with the official SDK MCPServer reportedly serves this template correctly when read directly, but behind a FastMCP proxy the template is listed and the read never reaches the backend (issue #5660). This suggests the failure lies in FastMCP-side template matching or routing rather than in the backend, but that is only an inference from the report, not a confirmed cause. Status: No maintainer response, confirmed root cause, workaround, fix commit or release appears in the supplied data. The reporter says they have a small fix with tests and plan a linked PR, but nothing is visible yet, so fix status is unknown. Practical diagnosis, limited to what the source supports: if you see a template listed but unreadable with a literal ? in its URI template, compare against this report's minimal example and version. Do not assume a particular release contains a fix. Limitations: This is a single external report with a minimal reproduction in the reporter's own environment on a dev build. It has not been reproduced by KFA. Comment coverage is partial, so later discussion may exist that was not captured.