Currently, MemorySegment::ofNativeRestricted is very monolithic. It's a one stop shop for creating a DYI segment with custom base address, size, owner thread, cleanup action and even attachment object.

With the recent addition of support for shared segments, it seems like having an explicit parameter for the owner thread seems less useful (after all, users can always call withOwnerThread if they so wish).

The only thing that is missing would be a way to attach a custom cleanup action to an existing segment; and, we don't really need an unsafe API for that - we can provide an API which "wraps" the existing segment cleanup action with some new action (which might be called before or after the original one).

If we had such an API, we could then simplify the API for creating restricted segment to only take a base address and a size - and if we move the API to MemoryAddress, we can simply take a size parameter. Clients will then be able to override confinement and cleanup action at will, using public, safe API methods.

As for attachment object, this (rarely needed) capability can be achieved simply by attaching a custom cleanup Runnable which embeds some other object that needs to be kept reachable. So,we don't need explicit support for that.