I agree that having the ability to have independent scenes that do not interact, when desired, is a big plus. I've encountered situations in Unity where I wanted to run a copy of parts of the scene and step ahead several iterations to predict where things will land for things like AI. In a general context, yes, this is desirable flexibility.
However, in the context of Unity, where the hierarchy and the way components and game objects are parented can have meaning that varies for different projects and prefabs, it is an inflexibility. Sometimes, this is fine, as inflexibilities allow for consistency. Going back to PhysX and how it is used in Unity, the ability for a rigidbody to have a collider that isn't parented to the rigidbody wouldn't make much sense.
On the other hand, if Unity had used a similar philosophy for Colliders as Obi, where in order for two colliders to interact they'd need to be parented to the same game object, there would be things that'd be a lot more difficult to do. For example, if you used additive scene loading, the two scenes' contents wouldn't collide unless everything that contained a Collider migrated over to another game object. Depending on how the scene and prefabs are set up, this could break existing relationships.
In your defense, I can understand how most use cases for Obi - e.g. cloth on characters - this would make sense. In these use cases it is a bit like a skinned mesh with fancier math attached. If Obi were more often used in the same way PhysX is, where players can play with it arbitrarily in some cases and very few assumptions about what the players may do can be made, I hope you can see why it wouldn't work. This is why I made the comparison.
A suggestion I'd put forth is to use parenting by default for the majority of simpler use cases. But in cases where game object parenting relationships are reserved for other purposes, it'd be a good option to allow actors to simply reference which scene they're a part of in a separate field. (Perhaps scenes could even be scriptable objects?) Otherwise, they'd fall back to a default scene when no scene is specified.
Requiring that developers cannot use the built-in Instantiate method provided in Unity for a feature to work correctly can be an issue. In the case of third-party assets, it'd at best be annoying to have to modify all of their code for compliance (assuming compatibility), and at worst, it'd be potentially unworkable without serious hack-arounds in case where you do not have source code access. Our project is early on enough that we could just ban the use of Object.Instantiate outside of our special replacement method that ensures compliance with Obi. But, as our project grows and other features are added - especially third party features - and they compete for control over how objects are laid out, it could become a headache that doesn't need to happen.
This all being said, no, not everything in our game is made of ropes, cloth, or fluid. But there will be plenty of objects that do have these things, and they can be spawned in arbitrarily. They'll need to be able to interact, and can move anywhere in the scene.
However, in the context of Unity, where the hierarchy and the way components and game objects are parented can have meaning that varies for different projects and prefabs, it is an inflexibility. Sometimes, this is fine, as inflexibilities allow for consistency. Going back to PhysX and how it is used in Unity, the ability for a rigidbody to have a collider that isn't parented to the rigidbody wouldn't make much sense.
On the other hand, if Unity had used a similar philosophy for Colliders as Obi, where in order for two colliders to interact they'd need to be parented to the same game object, there would be things that'd be a lot more difficult to do. For example, if you used additive scene loading, the two scenes' contents wouldn't collide unless everything that contained a Collider migrated over to another game object. Depending on how the scene and prefabs are set up, this could break existing relationships.
In your defense, I can understand how most use cases for Obi - e.g. cloth on characters - this would make sense. In these use cases it is a bit like a skinned mesh with fancier math attached. If Obi were more often used in the same way PhysX is, where players can play with it arbitrarily in some cases and very few assumptions about what the players may do can be made, I hope you can see why it wouldn't work. This is why I made the comparison.
A suggestion I'd put forth is to use parenting by default for the majority of simpler use cases. But in cases where game object parenting relationships are reserved for other purposes, it'd be a good option to allow actors to simply reference which scene they're a part of in a separate field. (Perhaps scenes could even be scriptable objects?) Otherwise, they'd fall back to a default scene when no scene is specified.
Requiring that developers cannot use the built-in Instantiate method provided in Unity for a feature to work correctly can be an issue. In the case of third-party assets, it'd at best be annoying to have to modify all of their code for compliance (assuming compatibility), and at worst, it'd be potentially unworkable without serious hack-arounds in case where you do not have source code access. Our project is early on enough that we could just ban the use of Object.Instantiate outside of our special replacement method that ensures compliance with Obi. But, as our project grows and other features are added - especially third party features - and they compete for control over how objects are laid out, it could become a headache that doesn't need to happen.
This all being said, no, not everything in our game is made of ropes, cloth, or fluid. But there will be plenty of objects that do have these things, and they can be spawned in arbitrarily. They'll need to be able to interact, and can move anywhere in the scene.