Is it possible to develop one application that can be be run in both: metro and classic style in Windows 8? I mean, application with the same core and two separate UIs, adjusted to currently used mode.
From what I've read and from the presentation I saw last night NO
Or at least not given the current tooling and support - as a for-example the Metro version of IE10 and the "desktop" version of IE10 are separate applications, they use the same rendering engine but they are distinct applications.
Further, delivery of Metro applications (again currently) has to be, let me emphasise that, is required to be via the marketplace (doubtless there will be corporate exceptions) - and the acceptance criteria for an app into the marketplace will preclude the code that would allow it to run on the desktop (one way or another).
Partly this is down to using WinRT instead of the current .NET framework - some sections of the library (including XAML) have been effectively moved into WinRT for Metro apps and the selection of the remaining System. libraries that you can use is constrained and partly this is down to want/expecting/requiring a certain standard of behaviour for Metro apps in order to maximise performance/battery life on tablet computers.
What you will be able to do, although I'm fuzzy on the details, is develop libraries that are portable between the two (at a source code level) as is already the case with some silverlight and phone code (you'll need to recompile not least because you will probably be changing dependencies from the System. to the Windows. namespace).
Edit: You can, in fact, develop "Portable Class Libraries" which is .DLL level compatibility but there are significant limitations on what namespaces are available to you - irritatingly (!) this will include interfaces/classes (like IObservable) that are used for view models in MVVM - which is one area where one might really like to share stuff (maximising common elements).
Is this ideal? That's a hard one - you can make a good argument either way (and its a safe bet that the windows team has chased this round and round in circles) but it does make sense, particularly in terms of moving the platform forward. I think how successful this is depends on how they make all of this work on large screen (lots of pixels!) and multi-monitor setups.
As @Murph said I am somewhat agree with their statements. Porting GUI Classic to Metro itself writing another library for just GUI change.
As I have explored about this, I got that it is possible with lots of efforts.
When you convert UI code from a Silverlight or Windows Phone application, you can use many of the same UI types, but the types are now located in the Windows.UI.Xaml namespaces instead of the System.Windows namespaces. These new UI types are similar to the previous .NET Framework UI types but contain some different members.
Check about Library Changes/ NameSpace Changes over here.
and Check List of Problems with Metro that gives information about the problem that app face in such transformation.
It appears that you will need to modify .Net for Classic Windows to make Metro Apps. So it's not JVM style drag, drop and run; even with different GUIs. The differences are more fundamental.