I'm not sure where to report SSMS bugs anymore - or check to see if it's a preexisting bug, but I've just found one that cost me several hours: when generating a SAS token from SSMS's object explorer to restore from a backup on blob storage, SSMS does not prompt you to overwrite a pre-existing expired token. As a result, the "generated" token is not saved as a credential and the restore fails with "Access denied" because it still tries to use the "stuck" expired one. The only way to get SSMS to actually use the new token is to manually drop the old one first by running the following sql:
DROP CREDENTIAL [https://<credential name>]
where <credential name> is typically the URL to the blob storage container, and can be found by running
SELECT name from sys.credentials
Once the stuck token is manually dropped, the user can then go create a new one through object explorer and the restore will finally succeed.
Instead of generating an unusable SAS token, I believe SSMS should check for a preexisting credential to that resource and prompt the user to overwrite it ("A credential for that resource already exists. Would you like to replace it with this one?"). If the user selects "Yes," SSMS first executes the DROP CREDENTIAL and adds the new one.