> That implies that all user code should be change to do the looping itself and be aware of region indices.

nope. That means that if a region other than 0 ought to be used, the user code has to be aware of the multi-region stuff. In the other case just pass a null pointer and get 0 for all queried quantities. (NB that the higher level code has to be aware of multiple regions even if the API of the PVT classes stays the same because it needs to instantiate the PVT objects.)

> I think that option ties the OPM (user) code too closely to the specific ECLIPSE models we happen to be implementing at the moment.

That's no change to the current situation: Every class which contains a method which takes a deck object is basically Eclipse-specific...

> In particular, the notion of a region index is very foreign in the case of a single, analytic function.

just pass a null pointer...

(analytic functions are also not aware of the concept of cells, BTW.)

> Oh, and another thing, it could very well happen that there is but a single PVT (or saturation function) region, but that the end-point scaling or hysteresis options vary from one cell to the next. That happens, for instance, in the case of Norne. By explicitly requiring that the caller be aware of region indices, we're also implicitly requiring that the caller be aware of all (relevant) region mappings that happen to be active in a particular scenario. I think that's the wrong trade-off.

that's true, but the caller probably needs to be aware of this in any case if it wants to use multi-region PVT and endpoint scaling. the question is rather where does it need to be aware: only during the construction of the property objects or also when calling them?