Let's review (with an example) why this situation happens.
Imagine that you are working in a changeset that loads the revision #500 of the "foo.c" file. Then, you change this file, but without checking it out. So, you have the revision #500 of the "foo.c" file changed.
Now, you switch your workspace to a different changeset, due to an update operation or a switch to branch/changeset operation. This new changeset is loading the revision #555 of our changed file, but you are still having the revision #500 changed.
When you try to commit the "foo.c" file, Plastic is going to identify that the parent of your changed file is not the one that it's supposed to be. Unexpectedly, the old parent #500 is the the parent of the changed file and not revision #555.
Why is there this error? It is due to it's a safe way to prevent having code regressions. Imagine that the revision #555 contains a bug fix that it's not present in the revision #500. If you finally commit the previously changed item, the bug fix is lost.
It also can happen if you have the item as changed and then you perform a merge operation.