I am currently running into another use case where I would want to use singleton and wanted to document it here.

I am working on an "ecosystem" of packages wherein I need to manage cross-package authorization. There is a core package and a series of packages that can be granted the ability to call permissioned functions from the core package.

I currently have a system where packages are granted authority by an AdminCap by whitelisting a witness type that is local to the external package. While whitelisted, the external package is allowed to call permissioned functions from the core package by passing in the witness type as proof of authority.

The issue with the above is that the external package just needs to pass in a witness type as proof. I have wrapped all permissioned functions so the witness type is created and passed in to the underlying core package function -- so, for the current contract version, there is deterministic security around (1) when the witness type is created and (2) how it is being used. The issue is that upon a package upgrade this determinism might not hold as you could just create a public constructor for the witness type.

Ultimately what you would want, from a transparency / security standpoint, is proof that the "witness" (using quotes here since it will likely be a struct with singleton + store and not a true witness) is a one of a kind. It's worth noting that although conceptually similar, a one-time witness cannot be used here as it only has drop.

This is a dumbed down version of what I have currently but gets the point across. Also, there are ways to get around this problem today, but singleton would be an simpler, more-intuitive approach.