I'd like to change BBL specific identifier at

to something more BBL specific since having BBL_BUNDLE="Custom" were triggering all those problems at the first place. But I'm not sure about overall impact of that change.

On the next run this Custom bundle getting removed since it is not enabled by the user.

Can we change this logic instead so it never remove the Custom bundle?

@Noisyfox , there are 2 options matching your suggestion:

1. Do not delete any previously installed profiles
2. Do not delete Custom profiles only

Which one do you prefer?

Note:
User may need to manually enable base printer config using 'Printer Selection' dialog for their profiles in order to make custom profiles visible.

Just to clarify, do users still need to do this if we end up with the solution of not deleting (either Custom or any) the profile?

I'd like to change BBL specific identifier at

OrcaSlicer/src/libslic3r/PresetBundle.cpp

Lines 47 to 50 in 2ea2ab0

	const char *PresetBundle::BBL_BUNDLE = "Custom";
	const char *PresetBundle::BBL_DEFAULT_PRINTER_MODEL = "MyKlipper 0.4 nozzle";
	const char *PresetBundle::BBL_DEFAULT_PRINTER_VARIANT = "0.4";
	const char *PresetBundle::BBL_DEFAULT_FILAMENT = "My Generic PLA";

to something more BBL specific since having BBL_BUNDLE="Custom" were triggering all those problems at the first place. But I'm not sure about overall impact of that change.

Also if you look at

I think what we could do instead is:
update this line

if ((vendor_name == PresetBundle::BBL_BUNDLE) || (enabled_vendors.find(vendor_name) != enabled_vendors.end())) {

which should prevent it from been delete, and also allow this profile to be auto-updated even if user hasn't select it, and also doesn't require user to enable base printer config.

We could even put this into a variable and reuse it, like:

const auto is_vender_enabled = (vendor_name == PresetBundle::BBL_BUNDLE) // always update configs from resource to vendor for BBL
    || (enabled_vendors.find(vendor_name) != enabled_vendors.end());
if (enabled_config_update) {
    if ( fs::exists(path_in_vendor)) {
        if (is_vender_enabled) {
            ...
        }
        else {
            //need to be removed because not installed
            ...
        }
    }
    else if (is_vender_enabled) {
        ...
    }
}
else if (is_vender_enabled) { 
    ...
}

Just to clarify, do users still need to do this if we end up with the solution of not deleting (either Custom or any) the profile?
It depends on the state of their system. For example, if we'll get preset bundle attached to the #8094 :

1. If 'Custom' profiles was removed then import of presets bundle will result in error message like

There are 0 configs imported. (Only non-system and compatible configs)
Hint: Make sure you have added the corresponding printer before importing the configs."

2. If 'Custom' profiles are there then presets bundle will be imported successfully:

There are 6 configs imported. (Only non-system and compatible configs)

All above is true for this particular case when custom profiles are derived from 'Custom' machines.

However, in general case custom profiles may be derived from other vendors (I have 2 profiles derived from Creality Ender 3 V3 SE). In this case user should enable dependencies first to get profiles imported correctly. This may happens if user have OrcaSlicer installed on a new machine and tries to import backed up bundle with no machine selection beforehand. It should be possible to automatically find and enable dependencies for profiles being imported from a bundle, but it definitely goes beyond this change.

As for this PR, it could be solved by changing BBL_BUNDLE value from 'Custom' back to 'BBL' with no logic changes at all. I just don't feel safe reverting it back on my own.

it was BBL specific until we changed that, so that when user installed Orca for the first time, the default selected printer in setup wizard is MyKlipper instead of Bambu.

Looks like it is better to revert BBL_* identifiers back to their original values and modify default values for initial setup dialog instead.

As for this PR, it could be solved by changing BBL_BUNDLE value from 'Custom' back to 'BBL' with no logic changes at all. I just don't feel safe reverting it back on my own.

This won't make things better, but rather make the disappeared profiles from custom to bambu, due to how this update check code is fundamentally broken.

Hmm, interesting.
Nice troubleshooting @buzzhuzz

At glance, I agree with @Noisyfox 's suggestion, make more sense to fix the code so that we won't delete the default profile(Custom) from the first place.