Sometimes I get accused of being a bit pedantic, but here I think I can offer some useful insights.
1. If you declare the recordset ANYWHERE in the form (class declaration area or top of a private subroutine), it exists only as long as the form is open. But, if such a thing makes a difference, you could declare the variable at the top of a general module's declaration area in which case the recordset persists if you close the form. The variables in a general module declaration area don't go away until Access closes (or if you are debugging and you do a code reset or take a trap that results in a code reset).
2. When using the recordset shared among many subroutines, particularly if they are called from events on the form, remember that you can't trust the position of the recordset's .BookMark property (that tells you where the recordset currently points). On entry to any subroutine that uses this proposed recordset, you will need to do a .MoveFirst, .MoveLast, .FindFirst, or something to let you know where you are.
3. You can certainly create a general module with tools to let you look into the recordset contents even if it is created in a class module. You would have to pass in the recordset as a variable if you do that because variables declared inside class modules normally don't exist from the outside of the class modules (i.e. not in scope of access). However, the VBA argument passage specification allows you to make a copy of the recordset (ByVal) or a usable pointer to the recordset (ByRef) as a formal parameter to a subroutine or function.