Thanks Kevin. Following up point by point, since several of my original questions weren't covered and a few new ones follow from your answer. Numbered so nothing gets lost.
Soil Sensor (Matter 1.5). Not addressed in your reply. Is the Matter 1.5 Soil Sensor device type supported in Home today? Your supported-types list names motion, ambient light, contact, temperature and humidity sensors, which implies no, but I would like that confirmed explicitly rather than inferred. Related: does any current developer seed or beta of iOS or iPadOS render the Matter 1.5 soil device types, or Water Valve 0x0042? If so I would like to test our firmware against it rather than wait for a release.
Are the substitutions sanctioned? This is my most important question. Until 0x0042 and Soil Sensor are supported, I am shipping valves as On/Off Plug-in Unit (0x010A) and soil moisture as Relative Humidity Measurement (0x0405). Both misrepresent the device. Is that acceptable to Apple, or does it create a problem at certification or Works with Apple Home review? I need this in writing before shipping.
Rejection granularity. If one endpoint declares an unsupported device type, does Home reject only that endpoint, or the entire accessory? If it is per-endpoint, I can declare 0x0042 natively and carry a compatibility endpoint alongside it.
Multiple device types on one endpoint. Can a single endpoint declare both 0x0042 (Water Valve) and 0x010A (On/Off Plug-in Unit) in its Descriptor DeviceTypeList, so certified firmware stays native and Home renders it via the type it recognises? Does Home pick the first supported type it finds, or reject the endpoint outright?
Composition vs Bridge. Also not addressed: for a controller with seven independently controlled valves, does Apple prefer one accessory with seven endpoints, or a Bridge (0x000E) exposing seven accessories? Bridge is on your supported list, so does bridging change how Home treats child endpoints whose device types are not supported?
Re-reading composition. You suggested rebooting the accessory. To confirm the mechanism: is a change to the root Descriptor PartsList alone sufficient to trigger a re-scan on the next reconnect, or does Home only re-read composition after the subscription is fully torn down? And is there any state Home caches across a reboot that would keep showing a removed endpoint?
Device type IDs behind the categories. You have confirmed no authoritative list exists. Can you at least confirm the specific device type IDs behind "outlets", "switches" and the five supported sensor types? Prose categories are not something I can design firmware against, and I am currently discovering support at pairing time.
HAP asymmetry. HomeKit has had Valve and Irrigation System service types for years, and shipping accessories render as sprinklers in Home. So Home can already express valve semantics; the gap is specific to the Matter path. Is a HAP-based accessory or a HAP bridge the sanctioned way to get correct valve semantics today, and is Matter parity with those existing HAP service types the intended direction?
Feedback reports, as requested: FB24694606 (Home app does not support Matter Water Valve device type 0x0042) and FB24694621 (Home app does not support the Matter 1.5 Soil Sensor device type). Both are also referenced under DTS case 6784027768.
