I would assume an upstream bug / feature request

I would support the new behaviour by strike out or grey out (like done in the search result for inactive repos)

Yes, this should be filled upstream, but I don't have an account there and maybe we can benefit from a downstream (here) review before escalating to upstream.

I will look at how difficult this would be to implement. It may be worth patching locally if it's a simple change.

What about commits to inactive repositories (e.g. rEZRM02fa55d0fcf43a896ba99c8d55a5bbeba026dac3 ) should those be rendered differently as well?

So the reason repositories are not rendered as closed is because the repository "Inactive" state is not the same as the "Closed" state in other objects such as Tasks. Repositories start out in the inactive state when they are created, then they transition to active once everything is configured for either tracking an upstream repo or hosting a repo directly. So that initial state should probably be treated differently (and it is) than a closed state. I'm not sure of a clean way to handle this and I suspect that upstream will see it as fairly low-priority unless someone wants to sponsor the project.

I believe this will be resolved by the 2019 Week 13 upstream release, which renders repository references like rXYZ as "closed" (with a strikethrough) if the repository is inactive. See https://secure.phabricator.com/D20309 for particulars.

Even after that change, commits are still rendered as "open" unless they are unreachable -- even if they belong to an inactive repository. I could go either way on what the better behavior is for commits -- in contexts where a commit in an inactive repository is mentioned, it's probably still a "live" object in the context of the discussion? But I'm not sure. Unreachability seems like a stronger / more useful thing to signal, perhaps.

An alternative rendering might be "rXYZabcd", but this would be a gigantic mess as far as the internals are concerned.

Awesome. Thanks all for your work!