So in my limited view:
When an image is sent into the print pipeline (driver-printer) without color management ( use of acpu or Drycreek f.i.) the print pipeline will use its rgb colorspace to transform and print the result. Thus in fact the combi of print pipeline and given paper.
This rgb colorspace of the print pipeline is a given. However I have a sneaky suspicion it is prophotorgb like.
Anyhow it seems to work.
You are correct that underlying assumptions are made about interpreting RGB color values. Most printers use some combination of inks, CMYK or multicolor, to create the actual print. The printer driver creates a mix of output depending on the received color values and applicable media settings. Cruder printers paired with a capable RIP do allow a one-to-one matching of input color value (CMYK or multicolor again) with output. More modern printers, however, vary dot size, spacing, and density in a way that you cannot control directly.
Sending RGB input to a printer with different outputs obviously involves a conversion. Whether there is an actual inferred color space, I can't say. The only printer driver implementation we have insight to is covered under NDA. As an example, however, if you print the same RGB input values directly to a Canon or Epson inkjet, you will obtain varying results depending on the media setting used. Look at the print under a loupe and you will see that not only does total and per channel ink limiting change, but so does drop size - by a factor of 15 in the case of Epsons.
The key point is that the process is consistent - as long as you prevent unwanted color management from occurring.
