Be Advised: Classified, FOUO, and PII Content is Not Permitted
Both SysML and UPDM utilize stereotypes and define "Tagged Values" (or just "Tags") for them. This is both a benefit and a curse, as they work differently than expected, since they are not just normal properties. In fact UPDM and some Custom Profiles go overboard in their usage of Tagged Value definitions.
For Example, the "Block" SysML stereotype has the isEncapsulated : Boolean tagged value property defined. That means if I create a "Car" block, what I'm really creating is a Car UML::Class with an Instance of the SysML::Block stereotype "in a composition relationship" with the Car class. This means that the "isEncapsulated" property of the Stereotype becomes a Slot of an InstanceSpecification (typed by the SysML::Block) that is linked to the Car class. (See UML 12.3.3.1.3). Confused yet? This has a few important side-effects that may not be totally obvious.
1. Technically, you can't start applying stereotypes unless the package structure the elements are a part of apply the Profile the Stereotype is defined in via the Apply Profile relationship. Most tools let you skip that step, but validation should fail. There are alot of Models or Packages where the SysML profile is not technically applied, even though the SysML stereotypes are in use. I also highly recommend staying away from the "Strict" boolean property of Profiles, as most profiles don't do a good job of specifying the proper metaclass imports (PackageImport or ElementImport relationships). Even the UML for SysML subset has issues, since InstanceSpecification (included in Strict SysML) is a specialization of Artifact (not in strict SysML).
2. InstanceSpecifications that have a stereotyped Classifier do not inherit the Stereotype of that Classifier. So my instance of Car (example, ChevyImpala) is no longer a SysML::Block. That means that they don't inherit the tagged value properties. Aka, there is no IsEncapsulated tagged value on my ChevyImpala. There are alot of UPDM stereotypes that had to be "duplicated" as InstanceSpecification extensions because of and to get around this. But that also means the InstanceValues of the tags don't get inherited. Even if I set isEncapsulated to True on my Car block, my ChevyImpala would have it unset. Not sure how this works for <<adjunctProperty>> or <<participantProperty>> when instances are created or simulations run.
3. Default values work differently with Tagged Values than normal properties. Normal properties will use the default value when Instance Specifications are created in most tools. But at least NoMagic MagicDraw or Cameo products don't create the defaults applied to Stereotype properties because they do not create the slots. Once you manually create the InstanceValue held by the slot, defeating partially the purpose of default values, the creation process will at least Default the value. This is horrible when it comes to applying something like a Classification stereotype property or some other mandatory property (Intellectual Property Rights or Distribution rights comes to mind...). Nothing in the UML spec says that Slots need to be filled when an Instance Specification is created, just that to be well formed, eventually the Slots must meet the minimum multiplicity to be a valid model. Remember Slots are like Software Pointers, they can start out "null" and only "point" to values being held elsewhere.
4. You can graphically visualize most properties on BDDs using the association or link relationships. At least in MagicDraw/Cameo you can't "pull out" tagged values in the same way. This means you can't show tagged type relationships graphically, which is unfortunate since graphical notation is part of the power of UML. It would have made sense to use the Link notation the same way. So for now, if you want to show relationships graphically, don't create a stereotype, just create a Class/Behavior/DataType that users of your profile can speciallize, just like we do with UML:PrimitiveType or SysML::PrimitiveValueTypes
5. There is a Boolean property of "Required" on the Extension relationship when creating your own profiles. Setting this to true is supposed to require the packages where the profile is applied to mandate the stereotype on any model element that has a metaclass that is a extended by that stereotype (inclusive of all specializations of that metaclass). Validation should check for this, or better yet, the tool should automatically create the stereotype instance when the element is created, but that is not always the case.
If UAF or other custom UML profiles really want to build traction, they need to understand these rules and how they interact and apply them appropriately in their specifications. Also SysML v2 will need to look very carefully at how to allow SysML v2 "Profiles".
I haven't played around with Sparx EA (in a while) or IBM Rhapsody the same as NoMagic MagicDraw/Cameo in the same way, but would love to see how they work out the details.