I have to say it is hard to read what you are trying to say @PauloMorgado ... you seem to be supporting my case for a System.Xaml (or Microsoft.Xaml) but then seem to imply that it is only for UI. I'm confused.
I am glad you spell out the definition of Xaml. I have to do that a lot as well. Every letter in the acronym is important, especially X and A. As you know, applications live in a process whose host can be a variable of forms, whether it is a UI process as you suggest, and also a WF process, which can be hosted in IIS or Windows Service, or even a console application. Xaml can be used in any of those scenarios. It can in fact be used in an ASP.NET MVC application (or a WCF application, as I have done) if you so wish. As you state, it is a manner of declaring an object graph in an expressive (and powerful) manner, while also yielding the designer-friendly benefits for which Visual Studio is (maturely) built around for some time now.
So to answer your question, Xaml for WPF is exactly like what Xaml is for WCF, WF, ASP.NET, Console Applications, or any application for that matter: an extensible, serializable, human-readable, designer-friendly, object definition language used to (powerfully) define objects within the scope/domain of an application -- wherever that application may reside.
The funny thing here is that if System.Xaml was never made, and Xaml continued to live in PresentationFramework/PresentationCore, we wouldn't be having this discussion. But, since it was moved out, and made as a great and powerful dependency for all these different technologies (some more used than others), well, then we have a complicated problem, don't we?
Please let me know if I misread your comment/question.