don't disable machine name in rebuild form -- it prevents renaming of features

Renaming a feature that way is likely to do all kinds of unstable things for sites running it outside dev. Beyond unlocking, a Features handbook page should be linked to listing the likely problems if you were to just run around renaming features.

UI needs to be much more fool-proof than what a developer can do with the files (and database) in hand.

Actually, this is something we've wanted to do for a while. Sometimes you really want to export a feature with a new name (so you can disable the old feature from a distribution and modify a new version). Turned out to be a bit tricky in that you cannot export a new feature that shares components with an existing feature. So the trick was to disable the old module before exporting. This actually helps prevent problems since installing the newly exported version won't conflict with the old module since it's disabled. To make it clear what is happening, I added some javascript to display a message telling the user that the old module was automatically disabled.

The way I decided to handle it to prevent accidental changes is to display the machine_name with the Edit link on the Recreate form. Changing the human name does not change the machine name until the Edit link is clicked. Once the Edit link is clicked, then you can edit the machine name field. But also any changes made to the Human Name will still generate an automatic machine name. This is slightly different than normal behavior of machine_name fields, but is something I really wanted to do here to help keep the human name and machine name in sync when possible.

So to clone a feature with a new name, click the Recreate link for the Feature, then click the Edit link for the machine name. Then enter a new human name (machine name will auto update). Then click Download. You'll see a message telling you the module was renamed and that the old module was disabled.

Obviously it does not handle any rename within the *.module file or any other file. It only causes the feature itself to be re-exported with the new machine name. So this will work fine for normal features, but if you've added lots of other code to your feature you'll still need to do additional find/replace. Can't think of any good way to make automatic find/replace work well enough to implement that.

Considering the extra steps needed to do this effectively, and that seems like something that could have enough bugs/issues to it, it'd be better to wait till the ui in general works better for recreating (for example, there's a bug that css? files are lost -- too lazy to look for issue atm) or let contrib (http://drupal.org/project/features_clone [only does drush atm]) tackle it.

The problem with features_clone is that it just does a search/replace. The patch above actually re-generates the feature code with the new machine name, just as if it was creating a new feature. As with a new feature, it won't have any additional files or functions in it. If custom code has been added to the feature then the developer should be educated enough to know how to move that code over to the new module. For people with un-customized features the above patch will work in all cases whereas features_clone might not depending upon naming.

Rather that waiting for some magical ui improvements of the future, I'd rather start with the patch above and get people using it and refining it so we can make step-by-step progress forward. For example, somebody could take the search/replace code from features_clone and add a checkbox to the Recreate form to determine if a full search/replace is done on the new module. Somebody else can tackle getting other files migrated properly (I haven't seen the css issue you mention). Somebody else can tweak the UI.

But this is definitely functionality I want to see in Features itself since only Features can really ensure that the code is exported correctly with the new machine name over simple search/replace ideas.

I like the start made here. Yes, systematically regenerating a feature and its components is a lot safer than searching and replacing strings. For renaming existing bundle components, this patch might help: #1589118: Cloning of all supported Entity types by bundle_copy .

#1259362: Use machine_name element that's now in core for module_name went in and mentions that that would fix this, please re-open if that is not the case

thanks