There are a couple of possibilities for the symptoms you describe. Let me start with a description how the scheduling server system works.
Tests and test lists are stored in our Storage service, which uses a SQL DB for the actual physical storage. Nothing ever gets deleted out of this DB. We admit this is a flaw and are actively working on a new design to overcome this flaw. Thus deleted tests and test lists will still show up on the remote executor when you run any test list.
When you schedule a test list to execute, Test Studio will try to intelligently push into storage only those tests that are part of that test list and have changed. It does this by comparing the files date & time stamp to the one stored in the SQL DB for the test. If what's on disc is newer than what's in storage it will get pushed, else it will be skipped.
Where this may break down is if you call a subtest via a coded step. Test Studio is not yet intelligent enough to scan coded steps for dependent subtests. As a result that particular sub test won't get pushed into storage and the latest version won't get used during test list execution.
Another possible hazard is if tests were copied outside of Test Studio, such as in Windows explorer, the ID of the tests and test lists, which is stored within the file itself, will become duplicated. Now when you schedule this copied test or test list, it will conflict with what's already in storage.
If any of the above hazards sound like they apply to you, let me know and we'll work on overcoming the problem.