You will likely run into a conflict by applying two different Feature Control based Profiles to the device. To handle this situation you can clone the existing Profile and make the change that you'd like and then apply that specifically to the device in question. You may want to create a new folder/group and apply the modified version of the Profile to that group and then unassign the current Profile to that group so that you can freely move devices between the groups in order to toggle that setting on and off. 

When you have one profile installed and install a second one then the second one will expand the first
profile with his settings. The first profile keeps always all his settings. So the second one wont be able
to allow OS updates or other settings from the feature control configuration.
You will see on your webconsole that the second profile will be installed partially because it wont install
the feature control configuration but other configurations like application run control or bookmarks.

Like Matt already recommended you should exclude your device from your default profile and assign
a clone of your default profile to only your device. Like that you can edit the cloned profile freely and
dont have to worry about the other devices.

The nswer is device-platform dependent.

On the system level, Apple has very brief document on how iOS firmware resolves MDM policy conflicts, and Google do not seem to have any such documentation.  Even so, the Apple's description is not very informative. 

On the Soti MobiControl level, the situation is a bit more complicated, as some profile payload can be instantiated/deployed more than once by design and some cannot, but multiple MobiControl profiles with the same payload-type of conflicting settings may be targeted to the same device. 

If the payload types support multiple instantiation (e.g. Wifi) by design, then multiple payloads from more than one profile can all be successfully deployed, and there is actually no conflict and the extra parameters in subsequent payload(s) can be considered as simple "logical-OR or logical-AND" to the existing ones.

For some profile payload types that only make sense for single instantiation (e.g. "Authentication"),  whenever a payload has been successful deployed with a profile, another profile with the same payload type will not be able to be deployed, and have status "failed" for the correponding payload".  Thus, it is a "first-come-first serve" conflict resolution strategy

However, some other profile payload types (especially on Android device platform)  may have parameter that only make sense to be instantiated once.  If addtional profile of the same type happen to be able to be deployed successfully on a device, then it is likely that the settings from the last profile successfully deployed take effect.  Thus, it is a "most-recently-use" strategy for handling conflict in this case.  So, two devices in the same device group may have different settings if the conflicting profiles are deployed in different order.

Because of the complication and uncertainty mentioned above, when attempting to maximize reuse and reduce MDM administrative overheads, any partitioning of payloads into multiple profile for each device should be carefully and systematically planned to match factors such ascorporate workflow, organization structure/location, administrative hierarchy, etc.