Well, these two message types are very different from one another:
> rosmsg show sensor_msgs/PointCloud
std_msgs/Header header
uint32 seq
time stamp
string frame_id
geometry_msgs/Point32[] points
float32 x
float32 y
float32 z
sensor_msgs/ChannelFloat32[] channels
string name
float32[] values
vs.
> rosmsg show sensor_msgs/PointCloud2
std_msgs/Header header
uint32 seq
time stamp
string frame_id
uint32 height
uint32 width
sensor_msgs/PointField[] fields
uint8 INT8=1
uint8 UINT8=2
uint8 INT16=3
uint8 UINT16=4
uint8 INT32=5
uint8 UINT32=6
uint8 FLOAT32=7
uint8 FLOAT64=8
string name
uint32 offset
uint8 datatype
uint32 count
bool is_bigendian
uint32 point_step
uint32 row_step
uint8[] data
bool is_dense
Maybe just adding a 2 at the end wasn't the best choice of name, but honestly, I think it's as good as any other, because it's just that, a name. Between the two it should also be relatively obvious in which way the second version is better: it's more compact.
Regarding the question of dropping the 2 when moving to ROS2 I'd like to ask: why? Right now, interoperability between ROS1 and ROS2 is alleviated by the fact -- I think it's a fact, but I'm not an expert -- that many message definitions are valid in both versions. Quickly looking at the migration guide and the ROS 2 interface design, it seems that PointCloud2 is a valid ROS 2 message definition without modification. So isn't it nice to keep the ability for ROS1 and ROS2 systems to exchange PointCloud2 messages?
