Structure
Right now, you have your data at two different levels - a list for index 0 and a single value for index 1. You won’t be able to apply the same logic to both, since they don’t follow the same structure. That’s a non-starter. The structure needs to be the same. If one needs to be a list, they both need to be a list.
List Levels vs Lacing
I would generally suggest you don’t mix list levels and lacing. Lacing is just Dynamo’s term for implied replication structure. List levels do what lacing does, but with explicit control. There are very few cases where list levels can be used without overwriting the lacing structure of a node.
Node Structure
Every node input has an implied (or explicitly defined) input structure. Replication happens based on the expected structure. If an input expects a single number and you provide a list of numbers, the node “knows” to run for each number individually and return a list of outputs. When you have multiple inputs, the structure becomes more important because the node has to know how to handle how each input structure relates to the other input structures. If your inputs don’t follow the expected structure in an equal way for each input, then the structure falls apart and the node doesn’t know what to do. This is where you can use list levels to specify the level at which the node should replicate over the input. However, list levels may not be enough if your structure still can’t match the expected input. There is always a list structure that list levels apply to, but not every list structure can be applied to list levels. Sometimes you just have to change your list structure.
Replication Guides
Replication guides are similar to list levels in DesignScript but give even more control by specifying priority as well as structure. This can be enough to overcome some list structures, but, again, there are some structures that just don’t fit node logic and have to be restructured to use any type of replication.
Your Example
Applying this to your example above, the first step is looking at the node input structures (assuming that the property sets have been restructured as sublists). Object and propertySetDefinitionName seem to both expect singular values. This means you could easily provide a single object and multiple property sets (or multiple objects and a single property set) and the node would “automatically” apply everything correctly. If both inputs are lists, the node would assume that the original expected structure and would replicate across each input index individually (the inputs are now 1-to-1 for the expected structure). To do this for your list of lists of solids, you would need to have a list of lists of property sets. The problem with using list levels here is that your list of lists of property sets isn’t aligned with the list of lists of solids. It’s meant to be a list per solid. You’ve now broken the structure of the node and list levels alone isn’t enough to specify replication within the structure.
Hopefully that clears things up without giving you all the details, but the best solution is to always match input structures 1-to-1 until you can ensure that list levels are enough to take over the replication structure.
EDIT:
Here are a couple other threads that include some additional context or examples: