For those curious, this is the current behavior. It is most comparable to a "locked" state but is quite confusing to the user. My workspace and agent are still running so the admin would have to rely on an autostop limit and perhaps some automation with the API if they wanted to delete these workspaces.

The third option "locked" sounds like the best approach for the reasons you have outlined 👍🏼

If we let them use the workspace as normal, we introduce a potentially dangerous surprise and limit the power of our group managers. A template/site-admin would have to intervene to reliably kick a user from a workspace.

If we deny the removal until a workspace is deleted, we undermine the authority of the group manager since they do not necessarily have permission to directly delete a member's workspace. We could detect if the group removal operation would also invalidate the users' access to certain workspaces, then allow the group manager to do both removals in one operation. This could lead to an unexpected load spike. For example, a template admin removing a large group could launch hundreds of workspace delete jobs.

I still need to learn more on how groups works under the hood - but tbh this feels like we have yet to clearly define how the concept of groups and the control of different admin roles interact.

Yes, I was aware that orphaned workspaces can be a thing when permissions are revoked.

Orphaned resources are an inevitability. The locked idea is interesting, but I do not think they should be able to delete the workspace. If a user loses permissions to a resource, that means an authority changed their roles. That authority should be notified of the orphaned resources and handle accordingly.

Another reason to not grant delete is that an orphaned resource might be from someone removed from the product entirely and it is the same problem.

This issue is becoming stale. In order to keep the tracker readable and actionable, I'm going close to this issue in 7 days if there isn't more activity.