For my .esp I have not been using update .esm as a master. I have only been using skyrim.esm.

Any downside to that?

You're supposed to since if you don't your mod may 'undo' fixes contained in the update.esm. I don't yet, since every time Skyrim get's updated it seems to cause huge problems, but I'll make it a master before releasing for certain.

The others can give more detail.

There's no downside if your plugin doesn't override the same forms Update.ESM does. I generally leave my plugins without Update.ESM as a master. If your plugin has a lot of overrides to Skyrim.ESM stuff, it's probably best to add it as a secondary master.

Note: New CK doesn't seem to be able to remove masters, only add them

i add update.esm as a master file, even though my mod does not touch anything in the vanilla game.

my reason for adding update as a master is it requires it to be enabled at game launch or else the game will CTD before the main menu. the reason for requiring is because my mod requires skyrim to be updated (certain scripts will not work otherwise). even though having update.esm doesnt necessarily mean the user's game is updated to the latest, it at least helps weed out users who are still running 1.0 (believe me there are more than a handful, primarily pirated users)

merely stating that your mod requires skyrim to be updated in the description is not enough these days

Actually only pirate users. Skyrim shipped a day 0 patch on install that no legit user could avoid getting. 1.1 is the minimum legit version someone could be using, though at this point if they are, screw em. They're NOT someone modders should be expected to cater to when CK generated material requires a minimum version of 1.4.

I include Update.esm because you just never know when you'll end up editing an updated item. There is only one downside I can think of. If a particular edit gets updated again later your mod won't know about that. Weighed against only using Skyrim.esm though, I'll stick with this.

Personally I used to not use Update.esm as a master since I saw no need to. However, as of the latest patch I have noticed that in some cases you can't avoid it. For mounted combat, they completely changed the structure of the animations tree (many branches have an extra early split up to accomodate for the new mounted combat), which broke some versions of my Dual Wield Parrying mod. This new structure can only be found in Update.esm, Skyrim.esm is still very much outdated in this part, so the only possbility to fix it was to load Update.esm as a master as well.

That's one thing I don't really like about how Update.esm works. I think it would have been better all around if they had been finding some way to apply patches directly to the Skyrim.esm file so that we didn't need to worry about this.

New Vegas didn't have an Update.esm file, did it?

Something that people with mods which don't already have Update.esm as a dependency (then add it) should be aware of (besides the above reasons):
By adding it, all new formIDs the CK creates start beginning with 02- instead of 01-. If you've manually changed the 'next formID number' in the plugin (using 3rd party apps presumably), it may duplicate a form that already exists.

EG: if you have 01223333, add the update.esm, then have a new form that is 02223333 - this causes CTD (or other drama)... essentially this is a duplicate form - since the game-engine dynamically alters those first two digits (depending on load order). In-game both forms will be changed to have the same ID - drama ensues.

I dunno if this could ever be an issue in a pureCK mod, but it's something to be aware of if your mod has unresolved issues you can't find the reason for.

[EDIT: I agree with ALWAYS having update.esm as a dependency... since it would preclude any issues in the future should an update change something you modded.]

Whether one has Update.ESM as a master or not, one is just as likely to end up conflicting with it. Say PluginX.esp puts ten carrots in Alduin's inventory and was made while Update.ESM v1.5 was current. Whether or not Update.ESM is/was added as a second master, it will override Beth's edit if she were to, with Update.ESM v1.7, give Alduin ten apples. The only way to know for sure is not to add Update.ESM preemptively, but to check each Update.ESM iteration against your mods and make sure they don't both override Alduin's record and, *if needed, *comparing/contrasting Alduin's subrecord data and manually adding Beth's ten apples right alongside your ten carrots. Then and only then will Alduin have ten apples and ten carrots.

*Check with File > Data > Details both Update.ESM and PluginX.esp. Locate all overrides to [00] forms in PluginX.esp by sorting by FormID in the Details window. If both override the same form, 'patching' is necessary. I use FO3Edit, personally. There's no harm whatsoever in viewing plugins with *Edit and conflicts are more easily detected.

*With Windows 7 and bAllowMultipleEditors=1 in your INI, you can toggle between editors from the taskbar by mousing over the windows that pop up from the icon. If both editors have the same form up to edit, they'll line up exactly and make it really easy to spot any differences.

Personally, I'll not add Update.ESM as a master unless I'm referencing, directly or indirectly, a form it introduces. If it edits the same stuff, I'll just line up the edits manually. If there were a TES5Edit, its "Clean Masters" would aptly purge Update.ESM from the vast majority of mods including it as a master.

As much as I hate to disagree (believe it or not.. heheh); I think that may be mistaken. If User edits Alduin (for example), it's that altered object/ref/whatever that stores the apples to oranges (or carrots as the case may be)... not the dependency on update.esm (or the ESM itself obviously). By adding the update as a dependency, whichever version of the update.esm each User actually has on their system will take effect... which should have NO bearing on anything if the object/etc wasn't altered in the plugin (but will be if the update.esm's changes intentionally do that, hence the NEED to have updates.. regardless of dependency).

I started the preemptive thing because I practice 'strategic updating' - meaning that I wait a couple-few weeks after updates are released... to see what happens to everyone's mods - and how to fix those issues. That and eventually I won't be updating certain mods anymore (or even modding at ALL) - which could be before a new update is released.. thus my mod would revert the update's changing inadvertantly, and for however long someone uses my old mod.

I didn't even start playing Oblivion until like a year and a half or more after its release... and I know the patch issues in that game aren't as potentially mod-altering as in Skyrim, but just to show User-habits. My point is that people a couple years from now will be playing my mods (hopefully); and while unlikely, it's possible Ma Beth will release another patch after my mods' development stops.

[EDIT: The only real reason I personally see for NOT having update.esm dependency is for Users who don't actually have the file - which would cause CTD as soon as the game was started with that plugin. I'm fairly certain that was already mentioned above as being a non-issue, with the exception of out-of-touch pirates using ancient versions... which need to be 'weeded' out anyways.]

Trying to add Update.esm causes a problem with version control and the CK won't let you merge your esp to it's master. The error refers to the esp not being a DLC and asks if you want to continue. If you press yes, a popup appears informing you that the correct answer is no...lol

The CK is doing quizzes

No, it won't. In the event PluginX.esp overrides the same form Update.ESM updates, PluginX.esp will 'win', entirely negating the changes regardless of whether it's dependent upon Update.ESM or not. This can go both ways.

A) http://i.imgur.com/kUFro.png
B) http://i.imgur.com/DlSlx.png
C) http://i.imgur.com/z8Dgi.png
D) http://i.imgur.com/y9Phu.png

The bottom line is that, while the ground is still moving underneath our feet, we need to compare/contrast all the overrides to Skyrim.ESM forms in our mods against the current Update.ESM to prevent conflicts any degree of certainty. Thus, as always, it's best to do things with as few overrides as possible.

But you just proved MY point... by editing the ref or object, User has created a NEW ref (which as we all know, in an ESP it overrides the ref in any ESMs... like you say). What you're not getting is that if that ref was NOT altered, that apple would NOT change simply because the mod has update dependency. If that were the case, every plugin with update-depen would be huge - full of senseless copies of the update.esm changes it never uses... which is what your posts suggest.

By changing the ref, whichever items/stats/etc that are currently loaded in the CK (ie: whichever version of update.esm is loaded, if any; AS WELL AS OTHER ESMs) will be saved to that NEW (and overriding) ref in the plugin. Show me an example of apples to oranges where the ref wasn't altered at all... it'd be a neat trick - and I'd shut up.

The only reason I'm being a little adamant about this, is because doing a comparison/search is beyond the ambition of many modders (myself included given that I believe it's overkill). By saying that it's ok to NOT have update.esm if the mod doesn't need it IS correct, and I used to take that approach... until I found one of my mods actually was affected by the update (which I actually haven't updated yet.. heheh).

As I said above, there are plenty of instances where mods have been abandoned (and continue to be everyday I assume) - and will overwrite the update if not preemptively set up (or done out of necessity in the first place, obviously). If modders just do the preemptive approach to update.esm, it saves a lot of time - and drama from having forgotten or missed something.

[EDIT: I DO get your point about changing a ref with an old update being dependent during its last save... but that's not my argument. Do to the minimal amount of actual changes in the update (from version to version), I believe it's more prudent to be preemptive and/or old-depen rather than leave a mod in it's 'orig vanilla' state. I suppose that summarizes my argument better.]