Liquibase doesn't uniquely identify the Change objects, only the changeSet.
You do normally want one change per changeSet, though. You want to do that because liquibase tries to run each changeSet as a single transaction but most databases auto-commit after each DDL statement (create table, etc.). If you have a changeSet like "createTable A" + "createTable B" if A gets created successfully but B fails to create for some reason, the databse cannot roll back the creation of A and you are stuck in a bad state where liquibase will try to run the changeSet again next time but will fail with "table A already exists". If they were separate changeSets, then liquibase would know A already exists and just try to re-create B.
In the case of insert, update, delete statemetns where you can have multiple change tags per changeSet and it all runs transactionally but that is a relatively rare case in liquibase usage.
Also, you normally don't want to go back and edit existing changeSets because you don't know what other systems may have ran them with the old definition. If you have a changeSet createTable and decide a column needs to be renamed, you want to create a new changeSet with a <renameColumn> change rather than editing the original changeSet.
Finally, if you are looking to work with liquibase programatically, you should look at the existing java API liquibase provides. It already has methods for parsing an changeLog into an object model and serializing a DatabaseChangeLog object back into XML and other formats. It may save you a lot of coding and also be able to handle more cases than your JAXB parsing would.
Nathan