I’d also say that, as you pointed out, we’re not to the point where we’ve decided on the bag format. In ROSBag version 2 (which is the current version used in ROS 1: http://wiki.ros.org/Bags/Format/2.0), it assumes ROS 1’s serialization and ROS 1’s topic properties (like latching = true/false). One option would be to do a ROSBag version 3 which would have the ability to store arbitrary connection information and serialized data. Then you’d just need the right plugin to read or write a particular format for the data. If we did that, then we’d probably consider trying to backport this to ROS 1 and create migration tools like we did with ROSBag version 1 -> version 2 (http://wiki.ros.org/rosbag/migration).
Another option would be to use some other existing data format scheme like hdf5 (https://support.hdfgroup.org/HDF5/) or something like that. We’re keeping an open mind about reusing more broadly used solutions, but the rosbag format has familiarity and commonality with ROS 1 in its favor. Until we come up with a concrete solution for ROS 2, I think you have to assume the format might be different from what’s in ROS 1. Either way, we’re aware that people have loads of rosbags already and will need to either have them work natively in ROS 2 (through the bridge or a plugin maybe) or have them easily converted to the ROS 2 format.