1. Yes and No. I use RO parameters, just not the OOTB ones. As many OOTB parameters I find them flawed (I agree they should be reporting parameters since they are driven by door geometry and frame type). So I don't use OOTB parameters AT ALL.
I created my families for usage with other firms, and yes, they do (sometimes) have construction under the same roof. And it drives GC's nuts if they don't have a RO parameter set. (btw: I often have 2 sets of RO parameters, for structural part and non-structural part of the wall)

2. Reporting parameter reading the actual opening size. Void size is based on a fixed offset from door frame depending on Frame Type (wood, steel, aluminium, plastic) and Wall Construction Type.

1. Here when we dimensioning an opening we put a dimension that has rough width/rough height aspect. As you know Revit has a built in function on dimension property that let you automaticly display Opening Height. The problem is that built in function instead of reading Rough Height is reading just Height. So, because I cant`t read Rough Height with this feature, i have to make Height to be the real "rough height". So, in the parameters list i have Rough Height=Height, Rough Width=Width, instead of losted width and height i define some shared parameters Unit Width and Unit Height.

2. Rought Width and Rought Height are not for input, they are driven by formula that depends on values of Unit Width and Unit Height.

Theoreticaly this is the logic path.

But practically it is slowing me a little because, usually, in the school we`ve learned what are dimension for Rough Dimensions for different rooms, and in reality, a lot of suppliers from europe have the doors feeting in this kind of rough dimensions. Plus, i can`t know from the project phase what brand the cliendt will choose, so, I really don`t know the real Unit dimensions, but I know that before buying the Units, the opening in the walls will be already there in the field, and that openings will be based onRough Dimenisons. That`s why it`s difficult for me to stay with the logical theoretical method, where Rough dimenions are drived by Unit dimenions. I usualy put a blind Unit dimenion so i can see in the calculated Rough dimension field the value i need it for Rough dimensions. Typical Rough Dimension for width here are 800/900/1000 mm. For Height 2100mm(anyway i put 2200 because the first 100mm are from the bottom concrete slab until on the finish floor).

p.s. here the low isn`t very strict for fire exits if a given number of width dimension for evacuation of people has to be applied for clear width inside the unit or for rough width. So that`s why is a little easy to us to continue thinking in rough dimensions. But in the countries where this reglemented dimensions should be for the real clear space inside the unit, then the Unit dimension is very important.

Like Martijn I try to avoid OOTB parameters, and try to use three pairs of custom width & height "opening" SP; "structural", "clear" & "overall" - which gives us the flexibility to schedule what we need (and when) for different purposes.

I tend to tie the "rough" OOTB height & width parameters to our "overall" parameters because (to date) that's how I've understand their intent (ie. the family's full dimensional extent, not simply the opening) but perhaps I should rethink that, and tie them to our "opening" parameters instead, if that's what contractors-in-BIM would rather.

Also, rough width and rought hieght parameters are broken for Curtain Panel Doors, so we use "Height" and "Width" so we can schedule Curtain panel doors and standards doors together

When models come into that detail, my option is to use a frame with a shared door inside.
The frame reports the rough (structural?) opening and the clear, while the door reports the nominal (overall?) size of the door.