Mysql Range partition
Think of it this way -- REORGANIZE PARTITION reads the source partition(s) and creates the destination partition(s), putting each row wherever it belongs. If the source range and destination range are identical (but broken up differently), then nothing can get lost.

Some comments on the schema:

PRIMARY KEY (`idMsg`,`idVeh`,`tmMsg`),


idMsg is unique; tmMsg needed to be added because it is the "partition key".  But is there any reason to include idVeh?  (There may be, bot note each of your 4 secondary keys will include all 3 of these columns -- somewhat bulky.)

KEY `X3` (`tmMsg`),


It is usually useless to have the partition key at the start of an index.  (Again, you may have a good reason; I am suggesting that this might be a useless index.)

KEY `X4` (`idVeh`,`tmMsg`,`idTrigger`)


Unless you are using = when testing tmMsg, this index is unlikely to get to the idTrigger column.  (Again, I am asking you to justify it; there could be a SELECT that shines because of this index; but it seems unlikely.)

`amLat` double DEFAULT NULL,
`amLong` double DEFAULT NULL,


Are you tracking fleas on dogs?  16 significant digits is overkill.  See here.

About the only benefit in PARTITION by a time is to purge old data. (DROP PARTITION is a lot less invasive than DELETE.)  If you think you are getting some other performance benefit, let me know; I may argue with you.