Here is a concrete example that I should have attached to the original post

I like the idea but we could bikeshed about the name (hints.labels?) and I am not sure this niche use case justifies the extra config complexity.

hints.labels seem much better name to me, but let's wait and see if there are other opinions. I'm also concerned about the config complexity, however after testing this change (I have a PR ready to go), I think this behaviour fits qutebrowser very well and is a good alternative to the current system.

I think one solution to the config complexity problem is that this could be an option for hints.mode. However, this could limit the possibilities to set the chars and labels by the user (although I think the '←↓↑→' <-> 'hjkl' labeling would be of most interest to users). This approach would also have the advantage of discoverability as users are more likely to test out different hints.mode options than stumbling upon the hints.labels variable and understanding it.

Thanks for opening an issue to talk about it before putting the PR up!
I would be interested in seeing if this could be implemented in a way that would help create an extension point for the extension API. Eg maybe there could be a hook or overridable method or a way to register new hint modes that would also enable implementing some other custom hinting schemes in a nice isolated way. Some other ideas around custom hints modes are discussed (and linked to) on #674

I like the idea personally. The use-case is narrow, but it could also be used to replace hints.uppercase which could be removed (with a suitable config auto-migration). The only drawback I see then is that people using hints.uppercase would need to define their hint chars in two places - though with a config.py this would just be c.hints.labels = c.hints.chars.upper().

I would be interested in seeing if this could be implemented in a way that would help create an extension point for the extension API.

This would be a nice thing to do, but seems pretty complex atleast for me and my small potential PR.

The only drawback I see then is that people using hints.uppercase would need to define their hint chars in two places

Another drawback would be that people using hints.mode word and hints.uppercase couldn't replicate the current behaviour with this change, although I think that is an almost non existent use case. An implementation that would support this is that hints.labels would be a dictionary, but that wouldn't allow for the c.hints.labels = c.hints.chars.upper() trick and I think a simple string would be a much nicer type for hints.labels.

Aside from the problems removing hints.uppercase would cause some users, this seems like a nice way to do this as we would get more functionality with the same amount of configuration options.

Another nice way to utilize this would be by using "roguelike" keybinds to add diagonal arrows to hints, which would match the default number of hint characters.

c.hints.chars = 'hjklyubn'
c.hints.labels = '←↓↑→↖↗↙↘'

Is this issue worth a PR or should this be put on hold until a more robust way of creating new hint modes is implemented?

I'd be fine with a PR implementing this in a way it replaces hints.uppercase, with a suitable config migration (and tests) in YamlMigrations in qutebrowser/config/configfiles.py. Also, the docs should probably show an example on how to replace the old setting when using a config.py.

Excellent. Now it's only a matter of time before someone ends up with the Konami Code as a link hint.