This allows us to write:

try(ISentryLifecycleToken ignored = scopes.makeCurrent()) {
	...
}

and rely on AutoClosable to clean up scopes.

👍 why do you have to disable this warning? Does it complain every time you're not using the API with a try block?

It complains about not using the variable (called ignored here) inside the try {} block.

To fix breadcrumb ordering across multiple collections when combining scopes - so we can maintain insertion order as well as possible. If this isn't good enough we might need some atomic counter we increment for each breadcrumb.

Implemented in #3355

Deleting certain things from scope can be tricky with new API since deletions might go to the wrong scope. Maybe we should just delete from all scopes. On the other hand a user might just want to shadow something temporarily so maybe deleting everywhere isn't wanted.

When calling removeX on current scope where scope has been forked since adding e.g. the tag in a parent scope, the remove only removes it from the current scope, not from the parent.

Good point, yeah that's tricky!
From a user perspective, I expect it to behave in-sync with setting a value, so I wouldn't remove the value from all scopes.
I'm wondering if we could treat remove<xy>() like a set<xy>(null) instead.

When retrieving scope values we then would need to change the behavior as well. From ~

return current.value ?: scope.value ?: global.value

To something like this ~

return if (current.isSet) {
	current.value // can still be null
} else if (scope.isSet) {
	scope.value
} else {
	global.value
}

Yeah I agree on not removing from all and making it behave the same way set does.

Not so sure about setting null and returning that because how do you ever unset this?

As a workaround for users actually wanting to clear certain values from all scopes, we could offer a ScopeType.ALL where we send set, remove etc. to all scopes, when they run Sentry.configureScope(ScopeType.ALL) { scope -> ... }

If users want to shadow something in the sense of temporarily unsetting, we'd have to use Optional for all values I guess.

This would allow users to use .configureScope() and be able to access the combined view of all scopes relevant, so they can read the same way SentryClient would.

The use case would be relevant for reading data from the scope right?

Yeah, cross platform SDKs (via InternalSentrySdk) are the primary use case atm. I'm about to play around with this but I'm gonna need help testing cross platform SDKs after the change.

move to CombinedScopeView as well?

Implemented in #3361

Implemented in #3361

Implemented in #3361