Hey @vaishhg,
As I tried to explain there are no nested dependencies. *.rs is a full blown scene file format which can express geometry, curves, simulation data, materials and more. When you save a Cinema 4D scene as *.rs al data in it is exported to that format, including the "nested" case where a *.c4d scene is referencing a *.c4d scene.
So when you start out with this *.c4d scene:
Scene.c4d
+-- Objects
+-- Cloner ( creates 5 instances)
+-- Cube Generator
+-- Cache
+-- Polygon Object
+-- Tags
+-- Material Tag (references 'Red Material')
+-- Materials
+-- Red Material
And then export it to Scene.rs, you get this (this is not an actual depiction of the file format, just a visualization of what happens, rs is not an open format).
Scene.rs
+-- Objects
+-- Cube.0 [Red Material]
+-- Cube.1 [Red Material]
+-- Cube.2 [Red Material]
+-- Cube.3 [Red Material]
+-- Cube.4 [Red Material]
+-- Materials
+-- Red Material (contains Red Material definition)
If you load that file back into Cinema 4D you get this. All data - that these are 5 separate cubes with a red material each - resides in the Redshift core only, we only see a proxy in Cinema 4D, hence the name "RS Proxy Object". It is the Redshift Core which will resolve the data in the RS file at render time.
ReferencingScene.c4d
+-- Objects
+-- RS Proxy Object.0 (loads Scene.rs)
+-- Cache (will be empty by default, there is literally no data in the c4d core,
only when we set 'Preview' to 'Mesh' there will be a cache so that the
viewport can display something)
+-- Polygon Object (one blob representing all 5 cubes and no material information)
+-- RS Proxy Object.1 (loads Scene.rs)
+-- Cache
+-- Polygon Object
When we now export ReferencingScene.c4d to ReferencingScene.rs we get this. Because when the exporter runs, it will encounter the two RS Proxy Objects when flattening the c4d scene and do what you cannot do, grab the rs scene data from the referenced Scene.rs files and inline that into the new ReferencingScene.rs file. So we end up with 10 cubes in total, each with the red material assigned.
ReferencingScene.rs
+-- Objects
+-- Cube.0 [Red Material] (from RS Proxy Object.0)
+-- Cube.1 [Red Material] ...
+-- Cube.2 [Red Material] ...
+-- Cube.3 [Red Material] ...
+-- Cube.4 [Red Material] ...
+-- Cube.0 [Red Material] (from RS Proxy Object.1)
+-- Cube.1 [Red Material] ...
+-- Cube.2 [Red Material] ...
+-- Cube.3 [Red Material] ...
+-- Cube.4 [Red Material] ...
+-- Materials
+-- Red Material (contains Red Material definition)
And when we load that back into Cinema 4D we get this:
SecondGeneration.c4d
+-- Objects
+-- RS Proxy Object.0 (loads ReferencingScene.rs)
+-- Cache
+-- Polygon Object (one blob representing all 10 cubes and no material information)
The TLDR is that the Redshift Core can read *.rs files and the Cinema API cannot, it can only write them or load them via an RS Proxy Object. And there is no 'resolving [...] the full proxy chain' as you put it. An *.rs scene file is just a discrete scene representation that contains does not know concepts such as generators or assets known to the Cinema API/Core. When export a *.c4d scene that references *.rs files all data is just flattened into a single *.rs file (again, what I showed under the *.rs formats above was just a visualization, not the actual file format).
There is currently no way to do what you want to do, even if you would request access to the Redshift Core C++ SDK. Because the RS file format is a GPU scene file format and very deeply integrated into the core. Even the RS Core SDK does not expose functionalities to read RS files to CPU memory structures.
Cheers,
Ferdinand