This is probably because you're using addModules and not addModuleStyles/addModuleScripts which have special handling for the cache invalidation of user modules.

Change 218552 had a related patch set uploaded (by Jdlrobson):
Don't mess with the cache

https://gerrit.wikimedia.org/r/218552

Change 218552 merged by jenkins-bot:
Don't mess with the cache

https://gerrit.wikimedia.org/r/218552

• https://gerrit.wikimedia.org/r/218552 (branch master): WMF-deploy-2015-06-16_(1.26wmf10)

Indeed. Using addModules() means the modules are requested through mw.loader.load() which builds the load.php url based on version information from the startup module which is shared with all users. That version will not change when you change your own user script because the general "user" module implementation hasn't changed.

This is why user-specific modules are always embedded as their own load.php request with a version directly in the html so that invalidation happens directly for the user (since you get your own version string directly in the html). And this also improves caching by providing a url with a "version" that can be cached by the browser.

The current way of loading the user module in MobileFrontend is not supported and works by accident.

As @Legoktm pointed out, using addModuleStyles/addModuleScripts instead should mitigate this. Be sure to verify this by looking at the generated html output and looking for a <link> and <script src> for load.php..modules=user..only=styles and only=scripts respectively.

@Legoktm @Krinkle could you point me to where it gets added in core. Somethings not quite right. When I use addModuleScripts it is not appearing on the page :-S

It'll be in the page footer, the relevant code is in OutputPage::getScriptsForBottomQueue().

@Legoktm @Krinkle the more I think about this I wonder if we should just enable common.css and common.js on mobile. This will cause breakage for some users, but might be a worthy exercise to identify for users to revisit their common.js scripts - what would be a responsible way to do this, given that some libraries are not available and some DOM elements that might be expected do not exist in the page?

I don't see what that has to do with this bug? Probably should be split into a separate bug since it's a different issue.

MobileFrontend currently uses its own separate user module which as this bug states has cache validation issues.
If we want this to stay separate we'd have to refactor core functions or do some nasty hijacking.
So actually not using this module would be another possible simpler solution to this bug. I'd rather clarify that we are doing the right thing by having a separate module before investing the time in fixing this bug.

Oh, you meant User:Foo/common.js and not MediaWiki:Common.js. Yeah, that makes sense and sounds reasonable.

But the fix for this bug is pretty trivial...

The concept is already generalised and is working fine for the "user", "user.groups", and "ext.globalCssJs.user" modules. Mobile can just do the same.

I see I need to be less vague here as I'm not getting myself understood.
There are two options

1. Mobile uses 'user' module. We break stuff
2. Mobile continues to use 'mobile.user' code, and either duplicates code in core to do so or makes core code more general.

For complete clarity..
The existing code is here:
http://git.wikimedia.org/blob/mediawiki%2Fcore.git/634ec8dc1e918aaee72e2227dfb443040dffcba6/includes%2FOutputPage.php#L3089

if mobile continues to use a mobile.user module rather than the user module L3103 will need to change to allow us to register other custom modules - it is not generalised in that respect.
http://git.wikimedia.org/blob/mediawiki%2Fcore.git/634ec8dc1e918aaee72e2227dfb443040dffcba6/includes%2FOutputPage.php#L3103

I'm asking if this is the preferred route or we should just make mobile use the same mechanism as core... the side effect of this is some user's mobile experience will break due to common.js modules not working on the mobile site.

I'm hoping this is clear as possible.
What am I misunderstanding if anything?

Change 233653 had a related patch set uploaded (by Legoktm):
Have mobile.usermodule cache invalidate properly

https://gerrit.wikimedia.org/r/233653

In T102554#1568954, @Jdlrobson wrote:

The existing code is here:
http://git.wikimedia.org/blob/mediawiki%2Fcore.git/634ec8dc1e918aaee72e2227dfb443040dffcba6/includes%2FOutputPage.php#L3089

if mobile continues to use a mobile.user module rather than the user module L3103 will need to change to allow us to register other custom modules - it is not generalised in that respect.
http://git.wikimedia.org/blob/mediawiki%2Fcore.git/634ec8dc1e918aaee72e2227dfb443040dffcba6/includes%2FOutputPage.php#L3103

No, it doesn't need any change. This code hardcodes "user" but that's only to implement the excludepage behaviour for live preview. The way the user module is loaded by OutputPage (e.g. parameters to makeResourceLoaderLink) is not special and exactly the same as what OutputPage does for any other group=user modules added via addModuleStyles/addModuleScripts by extensions. As example, the cache behaviour is working fine for ext.globalCssJs.user.

Change 233653 merged by jenkins-bot:
Have mobile.usermodule cache invalidate properly

https://gerrit.wikimedia.org/r/233653