RxTx communication with multiple slaves using a RaspberryPi
Consumer device, so component costs matter and an off the shelf product won't work.
  


When doesn't it matter in industry ;)


  
  The more devices I can connect the better. (My understanding is Modbus can do 250 devices by default, but I can do a double register(16bit) to get 65k tho bandwidth will probably cut that in at least half which is fine)
  


Technically you can only give slaves address 1-247 as 248-250 are reserved.  You could double the register address but then you wouldn't be compatible with any other Modbus device as you are no longer using Modbus Protocol.


  
  Slaves can be repeated many times. ie 10 of the same temperature sensors. I'm understanding that I don't necesarily have to define the slave id in modbus and can define it on the fly. Please correct me if I am wrong since I can't ask a consumer to set the ID manually if there is more than 1.
  


What do you mean by "design on the fly"?  If you are not going to allow your end user to define their own Slave IDs then I reccomend you initiate your own slave IDs to a higher number, like 150+.  If your device is connected to a pre-existing Modbus network then you might run into the issue of pre-exsisting slaves already using addresses that you assigned. YIKES!  Keep in mind that most end users will begin assigning devices at address 1 but that's not always the case!


  
  I need the consumer (true end user no corporate) to just plug a device in and have the system recognize what it is and be able to uniquely identify it.
  


Very easy to do but as stated in bullet 3, if your hardcoded Slave ID already exists on their system you will have multiple devices communicating to the same master.

Everything else you stated looks like standard Modbus RTU specifications so you should be fine there.  I would reccomend looking up Modbus TCP protocols for when you use wireless transmission.  Here is a helpful link to a website that goes over all of the Modbus Protocols as well as indepth analysis on what Modbus Erros and Responses need to look like.

Simply Modbus