On Form Customization: yes and no. It doesn't create the rules automatically, but you can add a resolver to create them (or add the creation code to an existing resolver). It probably will do them automatically someday.
Namespaces: The package itself can have only one Namespace (a limitation of Package Manager). It might work to specify others (below the package namespace) in the 'namespaces' member of the project config file. If not, you could create them in a resolver as above (or maybe better -- in a validator, so they'll be there before installation). I try not to modify the build.transport.php file unless absolutely necessary. You can *almost* always accomplish what you want in a resolver. Once you list a custom resolver in the project config file and create it, it won't be touched by MyComponent. Just be sure it has a unique name or is named for the package.
RemoveObjects nukes all the objects in MODX. If you run Bootstrap after that, they'll be recreated as described in the config file, then exported in that form by ExportObjects. That's why you're losing the rank. If you specify the 'rank' field in the project config file where you describe the TVs, it should be preserved, but I'm not 100% positive about that.
Personally, I never run RemoveObjects unless something has gone seriously wrong and I want to start over (IOW, almost never).
It's a failing of MC that when you update an object in MODX and run ExportObjects, the project config file is not updated. I mean to do it someday, but it's immensely complicated. That's why it's a good idea to update the project config file often and *not* a good idea to ever run RemoveObjects.
i think it will be more useful if you handle the following commands like this:
Bootstrap - automatically create transport package and install it through modx api
RemoveObjects - uninstall the package
Bootstrap is designed to be non-destructive so that you can add objects to the project config file and install them in MODX with Bootstrap without affecting existing objects. Doing it the way you suggest would overwrite objects in MODX based on the config file (which, much of the time, will not contain all the information you need for those objects - e.g., properties and TV options). You'd risk losing valuable work.
RemoveObjects is designed to nuke all the objects in the case where you've messed up and want to start all over, and uninstalling the package in Package Manager doesn't work correctly. Actually, I find it works best not to ever install the package on the dev. site using Package Manager. When I'm done (or nearly done) with a package, I build it and install it on another site. Using one site for developing the package and another for testing the install very often turns up problems with the install that won't show up on the dev. site because there are components or relationships there that aren't created in the actual install but need to be.
☆ A M B ☆
