@Halil has nailed it!
Deleting the FilesystemLocation entries manually rather than using the tank unregister_folders or the equivalent sgtk API commands, will cause issues due to the sync events not being created.
If you do ever trash a FilesystemLocation entity manually then you will likely need to run tank synchronize_folders --full per machine, which will essentially wipe out the local cache on the machine and then perform a full resync to match the FilesystemLocation entities in Shotgun.
You should normally be able to unregister folders by id, for example
tank Asset 1234 unregister_folders and this, as Halil mentioned, will unregister not just the Asset folder but also all the registered folders hierarchically underneath it.
If you rename the Asset you should still be able to unregister by id.
If you trash the Asset (even if you recreate one with the same name) you will need to unregister the asset by path instead: tank unregister_folders /projects/my_project/assets/my_asset. Again this will unregister not just that folder but all folders underneath it.
tank unregister_folders --all should remove all FilesystemLocation entities even if the associated entity was trashed.
One thing to watch out for is if you have a shotgun_list_field folder in your schema, and you register folders for example on your asset, with the type prop but then update the asset’s type to say env and create the folders again, it won’t stop you or warn you, but you will now end up with two sets of folders registered for that asset. The same appears to happen if you are using nested folder structures inside your yml files as well.