The simple answer is: we don't know yet. We actually had a conference call with some folks from Canonical a few weeks ago discussing this very issue. At present, it seems like there are three options (I'm taking these points mostly from the minutes from that call):
1. Port everything to Qt and use Mir (because GTK+ might not work under pure Mir -- they've been backing Wayland so far). This would require an IMMENSE amount of work and would be tantamount to rewriting almost every line in our codebase.
2. Help port GTK+ (or make an extension/fork of it) to Mir. This might honestly be less work than #1, but elementary would be at a specific disadvantage because most of our developers (speaking for myself as well) don't really have the skills needed for something like this.
3. Do nothing and use XMir until we absolutely must switch.
We don't have an official or internal consensus on this point yet, to my knowledge. However, I would personally tend to think we'll be leaning toward #3, depending on how XMir shapes up.
This is definitely an area of interest and importance for us, and it's something that will undoubtedly continue to be discussed as we begin the L+1 cycle and beyond.
- we rely very heavily on Launchpad - we rely on the hardware support and testing work they do - the Ubuntu userbase seems to be a bit more in-line with the kinds of people who will enjoy elementary OS (this isn't a technical reason) - we have some close relationships with Canonical/Ubuntu employees/developers
It's definitely a possibility, though personally I don't see it becoming feasible in the near term.
Kubuntu have already said that they will be using wayland and not switching to Mir, so you may want to talk with them, too. It doesn't seem like anything but stock Ubuntu will be using Mir.
What is concurrency and multi-threading support like in the language?
With Vala's object system built upon GObject, wouldn't targeting Qt be a problem?
For concurrency, I have personally written async vala code (which has some excellent support, including closures), but there is full thread support via GObject. The thread safety stuff is the same as the underlying library, and lots of work goes into GLib/GTK+ to make them thread safe where appropriate.
Yes, targeting Qt with Vala would a real problem. That's why we have absolutely no plans to move to Qt :) Not that it hasn't been brought up -- I remember some very vocal discussions in IRC a few years back when a few developers (mostly who have since moved on, interestingly) tried to convince us to jump ship and go to Qt. It was a lot more feasible back then too, since we were still pretty early in the Luna cycle. But the insurrection was ultimately quelled with practical concerns and majority mindshare :)
Doesn't GObject basically mean all the languages supported are compatible and we can write libraries/applications (which are generated into C code) and they are binary compatible with each other without extra code or configuration.
I think that's really interesting and could make very fast, and robust applications very flexible as well.
I am actually watching a talk on PyGObject by the author Tal Liron. https://www.youtube.com/watch?v=6QrGmA_RR4E