variable that references interface with same name but different casing renders referenced interface

[crowlKats]

The cause is mac & windows have case insensitive filesystems. probably best solution is to suffix symbols if there are multiple with different casing

[crowlbot]

I looked into fixing this and hit a design decision I'd rather get a call on before writing code, since it touches the public HrefResolver API.

The collision is real: Foo and foo in the same module both render to <module>/~/<name>.html, so on macOS/Windows the second page written clobbers the first, and every link to foo lands on Foo's page. (Even on Linux the pages are distinct, so it's only a problem for the case-insensitive filesystems.)

Suffixing the colliding symbols, as suggested, needs to know the set of symbol names in a module — a symbol's page name can no longer be derived from that symbol's name alone. That's the awkward part, because today the mapping "symbol name → page path" happens in two places that only see one name at a time:

1. href_path_resolve (the default HrefResolver), from UrlResolveKind::Symbol { file, symbol };
2. the file-writing loop in html/mod.rs, from symbol_group_ctx.name.

Options I see:

• (a) Carry the disambiguated name in UrlResolveKind::Symbol. Cheapest at the resolver, but symbol is also read for non-path purposes — usage.rs uses it to build the import example shown on the page — so it'd have to stay the real name and gain a sibling field, and every one of the ~24 construction sites has to supply it.
• (b) Give ShortPath the module's disambiguation map (Arc<HashMap<..>>, built once in GenerateCtx). No trait-signature change, and both places above already have a ShortPath. Costs a field on a serialized public struct, and third-party HrefResolvers that build paths from the raw symbol name keep colliding — though for them the URLs are case-sensitive anyway, so arguably that's fine.
• (c) Encode case in the file name unconditionally (e.g. percent-encode uppercase). Fully local, no map — but it renames essentially every existing page and produces ugly URLs. I don't think you want this.

I'd go with (b).

There's also the naming question, whichever option wins: given Foo and foo, does one keep the plain Foo.html (and which one — sorting is arbitrary), or do both get suffixed (Foo_1.html, foo_2.html) so no symbol silently keeps a URL its twin used to be able to steal? Suffixing only the "loser" keeps existing links stable for the common case where the collision was introduced later, so I lean that way, with the winner picked by first-appearance order in the module.

Happy to implement whichever you prefer — unassigning myself in the meantime so this doesn't look claimed.