Addresses and logical locations have a parenting mechanism to provide for caching. Adding a second caching mechanism for these creates unnecessary complexity for consumers that doesn't provide clear value. If producers provide an index, they can recapitulate duplicative properties for purposes of readability but they must remain in sync with the run level version. And so we should remove index.

Even after removing logicalLocation.index and address.index, the complexity we refer to still applies to the other cached objects threadFlowLocation, webRequest, and webResponse.

Part of the problem is that we have never clearly distinguished between two concepts; we have used the term "caching" to refer to both:

• Reuse: Multiple "local objects," for example multiple threadFlowLocation objects in result.codeFlows[0].threadFlows can reuse the same "cached object in run.threadFlowLocations by specifying their threadFlowLocation.index property.

• Inheritance: Those "local objects" can inherit some properties from the "cached object", while at the same time specifying other properties locally.

It is the inheritance part that really complicates the SDK. Therefore, we propose to remove the inheritance mechanism. For the remaining cached objects threadFlowLocation, webRequest, and webResponse, we propose to require that either the index property or a set of local properties, but not both, be present.

UPDATE @lgolding 4/29/2019: We are restoring the index property on address and logicalLocation. So this is no longer a schema change (although it is still breaking).