[Samsung Galaxy Nexus] MWisBest:
Based on the lack of other people stating anything about it, it's probably related to /data being encrypted (as mine is), so if your /data partition isn't encrypted you should be fine. I'm planning on adding a toggle for the "DexOpt /system to /cache" feature (that's where the dalvik-cache for things in /system is put in /cache rather than in /data, because in /data it eats away at your internal storage) for those who have encrypted /data partitions or want to use enormous GApps packages whilst using ART. I didn't want to scrap the feature entirely as it is especially useful for people like myself who have only 16GB of internal storage, most VZW Galaxy Nexuses have 32GB of internal storage. I'll probably put a little checkbox by the Change Runtime (switch between ART and Dalvik) option in Development Settings for this purpose.

There shouldn't be an issue with MMS and mobile data. Mobile data is something I have the utmost priority for despite how little I myself rely on it (I never even approach 1GB of data a month, rarely will I even get up to 512MB). [MENTION=5354353]DevVorteX[/MENTION] has been especially helpful with this, so big shoutout to him for that.

I'm not having this issue. The only thing I can think of is that if the Bluetooth tile is flipped, tapping on it doesn't turn Bluetooth on or off, it instead turns Discoverable Mode on and off, so make sure it isn't flipped.

I'd recommend going into the mobile network settings (long-way ya know) and clicking on 4G/LTE in the settings in there, just to make sure. There was a bug in previous builds pertaining to that which I've since fixed, and after manually selecting 4G/LTE in there everything should be back to normal (i.e. feel free to go back to 3G/CDMA or use the quick settings tile etc.).

While you're correct that FML is based on OmniROM, just because it's based on OmniROM doesn't mean crap from CM can't show up in it. I'm willing to bet money that every AOSP-based thing (as in like OmniROM, CyanogenMod, AOKP, etc., not just an AOSP ROM) has something from CM in it. OmniROM has done a good job at keeping that to a minimum.

At one point FML was based on CM, however CM was getting sloppier and sloppier and sloppier. Multiple people who had the rights to approve code in their Gerrit Code Review (this is a system where code that gets merged with a project can be looked over by people to make sure it's OK and if not it can be critiqued and improved until it is ready or be dropped altogether) would upload something of their own and then approve it instantly, without any further review by anybody else, which allowed stupid mistakes to get through that would not only have bugs in it, but in some cases it wouldn't even build at all. Worse, a few people were even completely bypassing Gerrit and just pushing their changes directly to git. The worst offender of this was Cyanogen (Steve Kondik) himself, for example there was a small change he made that was just about 4 or 5 lines, and he approved it in Gerrit immediately after uploading it, and it had a typo that broke CM nightly builds as well as an attempt at building FML that day, after that initial FML build attempt I saw what happened and took no more than a few seconds of my time to fix it. It was something that took less than a minute to stop a completely fresh build. A single minute of at least testing his change could have avoided the entire situation. Not long after that happened I found out about the whole Cyanogen Inc. fiasco and that was when I dropped using CM. There were so many times a change CM made would break something in FML, that I can't even count them on one hand.

Only one time has this happened with OmniROM, here:

https://github.com/omnirom/android_...mmit/32d6ec2315f55885761cc70c5acb62f983b24275

Oh and look where it came from:

https://github.com/CyanogenMod/andr...mmit/8f4976d10c2d355e4677647680f5d9f4bc41fc3b

Now, to be fair, this does fix a bug, however it introduces the possibility of another bug, in particular when the "-fstrict-aliasing" flag is used with the code compiler (this is one of those things that FML, like Linaro, does to speed things up, as it lets the compiler be less conservative in some cases in order to optimize things more), and worst-case scenario the compiler could maybe have an issue even without adding that flag and you'd never know until it's too late.

So as usual, another day another fork:

https://github.com/MWisBest/android...mmit/f002b5353b3e2a5b096b10f6527b6278d1861eea