for 1. - Yes.
Applications using UCK in a single domain will remain operational for now, they will just not be able to be deployed to a system that is using multiple domains.
for 3. - The answer is yes, we need to give up the uniqueness of contract keys in order to introduce full multi-domain support. We encourage you to build your models already anticipating this change.
Note that as of the time of writing, multi-domain connectivity in general is still a preview feature. We are trying to work to limit as much as possible potential breaking changes between the preview and the feature as it’s going to be delivered in general availability, but we are very actively developing this feature and we’re not at a stage where we can guarantee full continuity. As such, running this in production incurs in risks related to the completeness of the feature itself, as well as the stability of its API, both with regards to how it’s exposed externally and to the compatibility between multi-domain nodes across Canton protocol version.
Contract key uniqueness in particular is a topic which is very much under active development right now. Global key uniqueness is not feasible in an open network and we are trying to understand the exact semantics of non-unique keys in this environment, which makes the behavior of fetching by key something that may change between now and GA.
As mentioned by both you and @rohitt, however, if you want to enable your on- and off-ledger services based on Daml to be able to work on a multi-domain setting, you are definitely encouraged to experiment with multi-domain in development and testing capacity. The current limitations heavily restricts the usage of contract keys and you might have relevant findings relative to your application in the process of developing it with multi-domain compatibility in mind.