Thanks Nathan for your detail answer. Please find below some of my comments:
1. For #1 - As our orgnization's objective is to migrate flyway SQL scripts to Liquibase ChangeSet, the primary input for this migration is SQL Scripts that are already saved in Flyway. The historic information has to be retained, so if a script is run to add a column in 2013 and then another script was written in 2015 to delete the same column, then we need to maintain these steps in liquibase for historical references. With this, to get the correct 'known state' is also out of question, because historical steps will not be recovered with this approach.
2. Thanks for clarification on this, this is really helpful.
3. As it is a migration kind of requirement to migrate Scripts from Flyway to Liquibase, we GenerateChangelog/diffChangeLog would not fully satisfy the non supported objects and relations from SQLs. But as you have pointed out that creating change set ourselves would make sense to resolve these gaps.
We would have no choice it seems, but to proceed with manually migrating individual scripts from Flyway to Liquibase one by one using temporary database for execution of flyway script and then using GenerateChangelog on that changed DB and modify change sets generated to support non supported objects.
Thanks,
AcOne.