The build status that the "clone workspace" triggers on is not necessarily the same build status that gets recorded after all the remaining post-build-steps have run.
This can mean that the clone-workspace-scm plugin looks in the wrong folder for the archive file.
This also means that the plugin ends up leaving old archived workspaces on the machine.

e.g. consider the following scenario:

1. Project "Foo" defined as
   • Some build steps
   • Some post-build steps as follows:
     1. "Archive for clone workspace SCM" with a criteria of "most recent successful build"
     2. Publish JUnit test results, which can set the build result to "unstable" if any fail
2. Project "Bar" defined as
   • SCM of cloned-workspace from build "Foo"
   • Some build & post-build steps

And the following builds that happen

1. Foo build#1 runs.
   • Build steps are ok (result=SUCCESS).
   • Post build:
     1. it archives the workspace (as result==SUCCESS)
     2. all unit tests pass (so result stays == SUCCESS)
     3. Jenkins reports build as SUCCESS
2. Bar build#1 runs
   • it loads from Foo build#1 (as that's the most recent "success" build for Foo).
3. Foo build#2 runs.
   • Build steps fail (result=FAILURE).
   • Post build:
     1. it does NOT archive the workspace (as result!=SUCCESS)
     2. no unit-tests ran (so result stays unchanged)
     3. Jenkins reports build as FAILURE
4. Bar build#2 runs.
   • it loads from Foo build#1 (as that's the most recent "success" build for Foo).
5. Foo build#3 runs.
   • Build steps are ok (result=SUCCESS).
   • Post build:
     1. it archives the workspace (as result==SUCCESS). This means that it also deletes the archived workspace from Foo build#1.
     2. some unit-tests failed (so result is then set to UNSTABLE).
     3. Jenkins reports the build as UNSTABLE.
6. Bar build#3 runs.
   • it tries to load from Foo build#1 (as that's the most recent "success" build for Foo). It fails with a java.io.EOFException
7. Foo build#4 runs.
   • Build steps are ok (result=SUCCESS).
   • Post build:
     1. it archives the workspace (as result==SUCCESS). It also tries to delete the previously-archived workspace, but it doesn't find it, so it leaves Foo build#3's archived workspace on the server.
     2. all unit tests pass (so result stays == SUCCESS)
     3. Jenkins reports build as SUCCESS

Workaround:
None of this ever happens if one always ensures that the build archive step is always the very last step.
However, one often wants to trigger builds /after/ the archive stage, so it can't always be the last step.