@TomaszS: So, the way I look at classes is that there are two main types of classes:
There are "domain" / model / entity classes ... classes that have state (properties) and are vital to the business problem you're trying to solve. Their methods generally act on their own object instance.
Then there are utility classes that have no state, and play a supporting role. Factories, managers, orchestrators, facades. The methods act on instances of other classes (not themselves, because, again, they have no state).
Domain classes are generally not static. Factories, managers, orchestrators ... the generally ARE static
@currygoerge: as @jboemios said I think I address this later. In a nut shell, it has to do with the XML schema where the XAML rules or the XAML controls are defined. Back in the old days, some of the XAML controls (the default namespace) didn't have a name property defined -- it was already taken care of by the XAML rules (the x:). But I **guess** it caused some confusion and so they added Name to the default namespace so you don't have to use the x: namespace any longer.
@jonny: So, I don't work for Microsoft. I'm not sure what you're referring to regarding ASP.NET and WCF -- I never heard "it works across all Windows device families" as one of the selling points for those technologies. Nonetheless, I would encourage you to be informed, take a close look at the approaches to building adaptive apps (whether in this series or otherwise) and then you can make a decision whether this is for you or not. Universal apps is sufficiently different from ASP.NET and WCF that it would be hard to compare them.