I don't understand number 1 :confused: Are you saying that if an object needs a parent, make it a new rather than use a vanilla, or are you saying that any moved vanilla or new object needs a parent when in a vanilla interior cell?
Yes, and sort of:
Yes - If you move a vanilla object, cached saved game data can cause players to see it in its old location. Assuming you aren't recklessly breaking things by moving vanilla objects, giving these objects a new object as a parent can force the position to update if the parent gets enabled after the saved game loads. Helpful when you don't want to just replace it with an identical object. Alternately, cut/paste gives the object a new ID, also forcing the position to update if you don't want to give it a parent. 21603 has a post up here somewhere involving the same issue and a certain Lighthouse.
Sort of - new unparented objects don't need a parent to be present & in place, of course. However, the number of children a vanilla parent object has is cached in a saved game. So if you add more children to a vanilla parent, they might not appear in-game if the player has already visited the containing cell; furthermore, children objects you add might show instead of vanilla children objects for the same parent. I'm not sure what decides which shows.
To further illustrate:
Let's say Chorrol House For Sale's dining room set is parented by the big table and has 15 children. Modder Mike decides he wants a fully spread table, so he adds the extra few chairs, more dishes, and food. Thinking wisely that these things shouldn't appear till the player has purchased the dining room set, he makes them all children of the parent big table.
Downloader Dave, who has already purchased all the furniture for & moved into Chorrol House For Sale, then downloads & installs the mod & fires up his saved game. A sideboard & two chairs are missing, and there are three pieces of ham floating with no plates underneath three inches above the table, and the rest of the food pictured in the screenshot is nowhere to found. His saved game remembers that the parent big table had 15 children, and it's not willing to show any more than that. Downloader Dave then gives Modder Mike a litany of unkind words for his apparent epic failure, and Modder Mike spends three days banging his head on his desk between playtesting sessions trying to figure out why this keeps happening.
To fix invisibly to player: Make one of the added objects persistent and have it parent all the other added objects. Where & how to enable the new parent I suppose is circumstantial, and dependent on how invasive the modder is willing to be. I had to go so far as rig up a mini-quest for Benirus Manor to solve the problem in that house; plus literally cutting then pasting in place every vanilla object in the house, tying it all to a new parent, and adding an extra tag at the end of MS02 stage 110 to make it work every which way. It's horribly invasive, but it spanks the saved game and sends it to its room for sure.
Otherwise, the player can use the console in-game to target and disable, then re-enable the parent object. This will force the game to recognize & display the correct number of children; however, it will not fix objects being out of position. I'm not sure which is worse - the bloat and potential conflict of mucking about with scripts and quests and replacing vanilla things, or requiring the player to break end-user immersion to get the mod to work how it ought to anyways. The latter makes me feel like a Windows dev so I went with the former, and I just pray that some big mod more popular than mine that conflicts with mine will never come to fruition.
Or you can always just not parent anything at all, and force users to deal with the "don't install this till you've completed this" or "only works with new games", which again I think breaks immersion. I think if I'm putting something up for download, I'm responsible for if and how well it works, and that burden shouldn't be on the player...that's another rant entirely, nevermind.
Sorry for the wall of text. I'm terribad at explaining this issue, no matter how many times I've tried.
Number 4 - naming new base objects and new cells uniquely is wise, but changing the Editor ID of vanilla placed objects or cells is best avoided, simply because when trying to merge mods together with Gecko where one ESP changes the Editor ID of something and another ESP either also edits it, or contains the record but does not edit the Editor ID will result in a failed merge.
I didn't mean renaming vanilla things. I mean if you borrow a non-vanilla object or script or any piece of someone else's work to include in your own, make sure to rename it in case a player runs both mods. Redundant is better than broken. IE if you make a quest involving giving the player a temporary "Bag of Holding" & you borrow pieces from that mod to make it work, make sure you rename them all in case players using your mod are also using the actual Bag of Holding mod, else your changes could affect that mod depending on load order and what-not.
I'm hushing up now before I dig myself into a deeper hole.
Edit: Okay, for the record, I do want to say that yesterday I learned what a float is. \o/