Minor Scenario_1:
Job foo runs once and creates a workspace named "foo".
After renaming foo to foofoo the workspace "foo" still exists if it wasn't deleted manually.
If foofoo runs now it creates it's own workspace.
# ls foo foofoo
The problem by having multiple jobs with huge workspaces is the disk space. In addition to that it's not nice to have some dead folders lying around on your file-system.
Scenario_2:
If job foo is executed in parallel it creates multiple workspaces.
This is fine as long as you're not using the "Wipe Out Current Workspace" button.
If so the only workspace that is getting deleted is foo but not the additional ones.
Example before wiping the workspace:
#ls foo foo@2 foo@3 foo@4
Example after wiping the workspace:
#ls foo@2 foo@3 foo@4
- is duplicated by
-
JENKINS-25967 Job rename does not update reference to new workspace
-
- Resolved
-
[JENKINS-25912] Workspace remains on disk after job has been ( deleted, moved, renamed )
The problem of course is offline nodes while performing the action. Those simply cannot be updated.
Removing workspaces dirs manually involves at least one shell script which checks if no corresponding jobs exist any more.
And, when slaves do exist, it is not as easy as that.
I wouldn't mind a plugin, but it should be available as a feature.
Gaetano Giunta
added a comment - - edited Removing workspaces dirs manually involves at least one shell script which checks if no corresponding jobs exist any more.
And, when slaves do exist, it is not as easy as that.
I wouldn't mind a plugin, but it should be available as a feature. 
Straightforward workaround present (remove workspaces manually), therefore reducing priority.
Additional scenario: Roaming jobs probably also retain their older workspaces on other nodes when deleting the current one.