The way I understand it, the joint_state_controller is responsible for two things.
1) Publishing joint states
This is correct.
2) passing the current joint states to the ros controllers
This is incorrect.
The joint_state_controller only publishes current state, it does not do anything with other controllers or pass anything on to them (and it's also not an actual controller, but you probably had already figured that out).
With this in mind I don't believe the rest of your questions need an answer.
I would comment on this though:
To achieve this, the 'write' function in the ros_control loop would just publish to the 'joint command' topic, while the 'read' function would just pull joint states from the robot drivers' joint_states topic
If you really want to use ROS topics for in- and output of your hardware_interface, then I would recommend to not use the default joint_states name for that particular topic. It's only going to confuse people, and you will run into problems with the joint_state_controllerpublishing to /joint_states which your hardware_interface then reads.
Edit:
Would it be possible (and would this be frowned upon from a design perspective) to just do ros_control without the joint_state_controller - relying just on the joint_states published from my robot's driver node?
well, it's software, so you can do whatever you want.
I don't understand what you mean by:
relying just on the joint_states published from my robot's driver node?
who is relying on this? External consumers of JointState messages? Or your hardware_interface?
I see what you're saying about renaming the joint_states topic from my driver node to something else - but I feel it would be redundant and inefficient to have two joint_states topics with the exact same information.
Thing is: you're trying to make an adapter or façade which makes your driver/node compatible with an established abstraction (ie: ros_control). It's perfectly possible to use ROS topics for everything (although I personally wouldn't do it), but you will run into situations where it may be somewhat 'ugly'. That's often the case when adding a compatibility layer to existing code.
In the end, I believe it will depend somewhat on how much you value symmetry and the principle-of-least-surprise.
Symmetry would be improved if you'd use ros_control controllers to both accept new commands and publish current state (ie: use joint_state_controller to publish current state and use whatever controller from ros_controllers (or a custom one) to accept new commands). That's symmetrical as the ROS API of your control system would at that point all "live" at the same level of abstraction.
Having some "random node" (not really random, but from an architectural perspective it sort-of is) publish JointStates which I am to take as being one half of the interface to a particular robot/system seems "off" to me. But that's not really a technical issue, more of a design one.
Least-surprise is maintained if you'd use joint_state_controller to publish ... (more)
