Personally I would not recommend leaving deprecated prefabs in your project. If you're not careful, those deprecated files are extremely confusing for new team members, or when doing maintenance years down the road when you no longer remember every little detail. It also makes searching your project more tedious since your search results will include deprecated files.

I'd suggest either deleting the bad prefab, or just modifying to fix it rather than making a new version. If you ever need the old version again (why would you?) - that's what version control is for.

If you absolutely must keep the old prefab for some really legitimate reason and not out of a fear of ever deleting anything, you should rename it and include the word "Deprecated" in the new name.

Rationale

Deprecation is normally used in the context of public APIs/packages, where your team is creating code or other assets that will be used by other teams. You mark an API or other asset as deprecated when it's no longer supported and will be removed in a future version; the only reason you're keeping it around is for backwards compatibility, so developers that use your API/package don't have to immediately update their code to keep their project working.

When you are working on an internal project solo or with a small team, there's not a lot of reason to keep around deprecated files. You don't have to worry about breaking someone else's project when you remove an old version of a file (unless you're working on a shared library that is used by multiple internal projects). The biggest concern is if you are working on a large team where multiple developers might be currently working with the asset that you want to get rid of; then you may need to coordinate with them to make sure you don't do something that causes merge conflicts.

If you want to replace a broken prefab because it's not possible to fix the prefab, there's a way to replace the prefab, (usually) without breaking existing references to that prefab:

1. Create the new prefab that works correctly.
2. Minimize Unity and do not open it again until you reach step 5.
3. In your operating system's file browser (e.g. Explorer, Finder), find and delete the prefab file, but not the corresponding .meta file.
4. Delete the .meta file for the new prefab. Rename the new prefab with the same name as the old prefab.
5. Open Unity again.

What we've done here is replace the old prefab with a new prefab with the same GUID (this is defined in the .meta file). Any components that referenced the old prefab by GUID will generally still have their references to the new prefab. However, references to a specific script on the prefab will no longer be valid if the new prefab doesn't have the same script.

Personally I would not recommend leaving deprecated prefabs in your project. If you're not careful, those deprecated files are extremely confusing for new team members, or when doing maintenance years down the road when you no longer remember every little detail. It also makes searching your project more tedious since your search results will include deprecated files.

I'd suggest either deleting the bad prefab after creating a new version, or just modifying the bad prefab to fix it. If you ever need the old version again (why would you?) - that's what version control is for.

If you absolutely must keep the old prefab for some really legitimate reason and not out of a fear of ever deleting anything, you should rename it and include the word "Deprecated" in the new name.

Rationale

Deprecation is normally used in the context of public APIs/packages, where your team is creating code or other assets that will be used by other teams. You mark an API or other asset as deprecated when it's no longer supported and will be removed in a future version; the only reason you're keeping it around is for backwards compatibility, so developers that use your API/package don't have to immediately update their code to keep their project working.

When you are working on an internal project solo or with a small team, there's not a lot of reason to keep around deprecated files. You don't have to worry about breaking someone else's project when you remove an old version of a file (unless you're working on a shared library that is used by multiple internal projects). The biggest concern is if you are working on a large team where multiple developers might be currently working with the asset that you want to get rid of; then you may need to coordinate with them to make sure you don't do something that causes merge conflicts.

If you want to replace a broken prefab because it's not possible to fix the prefab, there's a way to replace the prefab, (usually) without breaking existing references to that prefab:

1. Create the new prefab that works correctly.
2. Minimize Unity and do not open it again until you reach step 5.
3. In your operating system's file browser (e.g. Explorer, Finder), find and delete the prefab file, but not the corresponding .meta file.
4. Delete the .meta file for the new prefab. Rename the new prefab with the same name as the old prefab.
5. Open Unity again.

What we've done here is replace the old prefab with a new prefab with the same GUID (this is defined in the .meta file). Any components that referenced the old prefab by GUID will generally still have their references to the new prefab. However, references to a specific script on the prefab will no longer be valid if the new prefab doesn't have the same script.

Personally I would not recommend leaving deprecated prefabs in your project. If you're not careful, those deprecated files are extremely confusing for new team members, or when doing maintenance years down the road when you no longer remember every little detail. It also makes searching your project more tedious since your search results will include deprecated files.

I'd suggest either deleting the bad prefab, or just modifying to fix it rather than making a new version. If you ever need the old version again (why would you?) - that's what version control is for.

If you absolutely must keep the old prefab for some really legitimate reason and not out of a fear of ever deleting anything, you should rename it and include the word "Deprecated" in the new name.

Personally I would not recommend leaving deprecated prefabs in your project. If you're not careful, those deprecated files are extremely confusing for new team members, or when doing maintenance years down the road when you no longer remember every little detail. It also makes searching your project more tedious since your search results will include deprecated files.

I'd suggest either deleting the bad prefab, or just modifying to fix it rather than making a new version. If you ever need the old version again (why would you?) - that's what version control is for.

If you absolutely must keep the old prefab for some really legitimate reason and not out of a fear of ever deleting anything, you should rename it and include the word "Deprecated" in the new name.

Rationale

Deprecation is normally used in the context of public APIs/packages, where your team is creating code or other assets that will be used by other teams. You mark an API or other asset as deprecated when it's no longer supported and will be removed in a future version; the only reason you're keeping it around is for backwards compatibility, so developers that use your API/package don't have to immediately update their code to keep their project working.

When you are working on an internal project solo or with a small team, there's not a lot of reason to keep around deprecated files. You don't have to worry about breaking someone else's project when you remove an old version of a file (unless you're working on a shared library that is used by multiple internal projects). The biggest concern is if you are working on a large team where multiple developers might be currently working with the asset that you want to get rid of; then you may need to coordinate with them to make sure you don't do something that causes merge conflicts.

If you want to replace a broken prefab because it's not possible to fix the prefab, there's a way to replace the prefab, (usually) without breaking existing references to that prefab:

1. Create the new prefab that works correctly.
2. Minimize Unity and do not open it again until you reach step 5.
3. In your operating system's file browser (e.g. Explorer, Finder), find and delete the prefab file, but not the corresponding .meta file.
4. Delete the .meta file for the new prefab. Rename the new prefab with the same name as the old prefab.
5. Open Unity again.

What we've done here is replace the old prefab with a new prefab with the same GUID (this is defined in the .meta file). Any components that referenced the old prefab by GUID will generally still have their references to the new prefab. However, references to a specific script on the prefab will no longer be valid if the new prefab doesn't have the same script.