To my understanding:

the TypedPropertyValue structure is the base encoding primitive for serialization of metadata in Windows property storage formats and it is used to define how a single typed value is serialized. This structure is originally defined in MS-OLEPS and is only documented in that spec, but is used differently in the MS-PROPSTORE format. MS-PROPSTORE does not adopt the OLE Property Set format; it simply reuses the same value binary encoding rules that originate from it. So when parsing properties in a property set that follows MS-PROPSTORE format, anything non-simple like VT_STREAM should be handled differently than it would be in an MS-OLEPS formatted property set.

I'm confused because the only documentation for certain variant type codes (for instance, VT_BSTR) is from MS-OLEPS, but they are still present in MS-PROPSTORE property sets. MSDN states that VT_BSTR must be a CodePageString and relies on a CodePage property defined within the enclosing property set. This doesn't make sense to me because MS-PROPSTORE property sets do not define a CodePage.

My conclusion that I'm not confident in:

MS-PROPSTORE uses the VT_* enumeration to identify value types and serializes values using the TypedPropertyValue structure, but it defines its own interpretation rules for those types. So VT_BSTR values for instance are not subject to the CodePage requirements defined by MS-OLEPS. In the MS-PROPSTORE format, VT_BSTR is serialized as a UnicodeString instead.

The part of the MS-PROPSTORE format 1.7 Vendor-Extensible Fields, is a mechanism for vendors to define their own property sets and assign them Format IDs so they can be referenced from a PropertyStore, but since this is MS-PROPSTORE, all vendor-defined property sets must be serialized inline with no complex/indirect references (they must be "simple" property sets). MS-PROPSTORE does not support non-simple (stream-backed or indirect) property sets, even though it allows vendors to define arbitrary property sets and property identifiers.