Users are asking me frequently for a XBox version of my app.
Unfortunately I do not own a XBox, nor would getting one make sense (it is a free app, so I am not really interested in spending lots of money just for developing purpose.)

Aside from my personal dilemma of a missing device, it would definitely make sense to be able testing code in an emulator first instead of having lots of hardware around all the time.

It's just the same like with mobile. Here we have several emulators, and I usually make use of them first instead of plugging a device immediately.
Even more important, XBox has a limited API with respect to desktop and mobile. (NetworkInformation object not available, etc.) So testing against a device or emulator is really essential. Personally I won't enable XBox without having tested my app first - at least in an emulator.

If Microsoft fears somebody could use the emulator for playing games on a PC, then just turn off games. An app-only emulator would be good enough. :)

Currently it is really painful to add new Controls from newer Windows SDK versions to apps and still support older versions.

There needs to be a way to define new XAML Controls/Properties/Etc., as currently if you want to add these, with a lower Minimum version, it has to be from code-behind.

Ways this could potentially be fixed:
Have a separate Class Library that only supports new SDK versions, and it will only be loaded into the app on newer SDK versions, therefore you can write safe XAML markup including new Controls and Properties.

Like how Xamarin.Forms does it, instead of <On Platform="IOS"></ On>,
we could have <On MinSDK="10.0.16190.0"><TreeView/></On>, then we could have an else conditional or something to have replacement XAML that would provide a TreeView like experience.

This would be really helpful when it comes to upcoming Fluent Design, supporting new Fluent Design Styles, and Supporting the Design Waves.

Alternatively, it would be nice if the UWP platform was updated separately from Windows, so apps would be able to support all the new Controls/Styles. I'm pretty sure the new TreeView is not Fall Creators Update dependent.

According to the documentation, it is possible to x:Bind events to a handler.
According to the docs:
"For events, the target method must not be overloaded and must also:

- Match the signature of the event.
- OR have no parameters.
- OR have the same number of parameters of types that are assignable from the types of the event parameters."

When working with parameters, this works as long as the parameters have the default names.

So for the CalendarView.SelectedDatesChanged event, the following signature works:
SelectedDatesChanged(CalendarView sender, CalendarViewSelectedDatesChangedEventArgs arg)

Now if you change the name of one of the parameters, as an example like this:
SelectedDatesChanged(CalendarView sender, CalendarViewSelectedDatesChangedEventArgs arguments)

Compilation of the Binding will fail because only default parameter names are assumed. This behavior is not found in public documentation. And honestly I would prefer to not have this limitation as it is totally counter intuitive.

In DX11 you can't read and write to the same texture, and that's fine, I can live with that.
However the API was designed that it will introduce severe overhead in the following scenario.

Say I have 100 objects to draw.
These objects are semi-transparent (alpha-blending) so I need to draw them sorted by distance to camera (back to front) and not by state changes.
Let's assume I have 50 objects which are Soft Particles (SP)
And 50 objects that are triangle meshes (TM)

Both SP and TM use alpha blending.
SP don't do depth writes, but they do depth-tests and depth reads in the shader. Depth tests are needed for fast skipping occluded pixels, and depth reads in the shader are needed for calculating particle opacity (to make them soft).
TM do depth writes and depth tests, but they don't do depth reads in the shader.
By depth writes I mean the D3D11_DEPTH_STENCIL_DESC.DepthWriteMask

So both SP and TM do legal operations (they don't write to the depth buffer and read in the shader at the same time)

However in the worst case, when SP and TM are ordered in the following way:
SP, TM, SP, TM, SP, TM, ..
I have to change the depth stencil view using OMSetRenderTargets for each draw call to set the same depth texture but with view that has D3D11_DSV_READ_ONLY_DEPTH enabled or disabled.
Remember that sorting has to be done by the distance to camera, and can't be done by state changes.

So in order to draw them all, I have to do:
for(Int i=0; i<100; i++) // for each object
{
D3DC->OMSetRenderTargets(..ID3D11DepthStencilView that either has D3D11_DSV_READ_ONLY_DEPTH enabled or disabled);
set depth writes enabled or disabled, set other state changes, make the draw call
}

To my understanding OMSetRenderTargets is a slow operation, but I need to call it 100 times.
And the calls to OMSetRenderTargets are really useless, because the same depth texture is used, just with a different view, and because both SP and TM do legal operations, they don't write to the depth buffer and read in the shader at the same time.

In my opinion the D3D11_DSV_READ_ONLY_DEPTH is really useless, and should be removed, any state validation for reading and writing to the depth texture should just check for D3D11_DEPTH_STENCIL_DESC.DepthWriteMask in each draw call.
However to don't sacrifice performance, those validation checks should be performed only in debug mode "D3D->SetExceptionMode(D3D11_RAISE_FLAG_DRIVER_INTERNAL_ERROR)", and in that case, the draw call should still be allowed, but it only should issue a debug warning: "writing to depth and reading from it in the shader may produce undefined results"
Inside the OMSetRenderTargets you have code to automatically unbind textures that are bound as render targets from shader inputs, that code should be removed as well.
You should trust the application to let it manage the correct state changes on its own, without introducing artificial limitations and sacrificing performance.

That way would be very beneficial:
-I don't need to create 2 depth stencil views for each depth buffer (one with D3D11_DSV_READ_ONLY_DEPTH enabled and one with disabled)
-I don't need to call OMSetRenderTargets for each draw call where I want to change D3D11_DSV_READ_ONLY_DEPTH. But I just stick to normal depth writes D3D11_DEPTH_STENCIL_DESC.DepthWriteMask

This would result in smaller memory usage, faster performance, smaller cpu overhead / power usage, longer battery life.

This artificial limitation is also the cause for bugs in WebGL 2 in Chrome/FireFox:
https://bugs.chromium.org/p/chromium/issues/detail?id=763695

Once you start working on WebGL 2 in MS Edge, you will notice that you will encounter the same problem, because in GLES3/WebGL2 it's legal to read from the depth texture while it's bound to the FBO, and you will have to do checks for each draw call if depth stencil view needs to be changed to have D3D11_DSV_READ_ONLY_DEPTH or no.
You will don't have to do these checks if this artificial requirement is removed from DX11 API.

Thank you

For example, MS provide the lot of sdk and new technologies about Win10 Fall CU. The SDK itself support the side-by-side installation, then we can try the new API with our UWP Apps.

But, there are no way to distribute this kind of app to testers or customers that use Win10 Insider preview. It only allow the Customer Update SDK level.

I belive that Store should control the SDK level more grained.
You know, many of Microsoft Apps are updated with new SDK, and it'll be available at the store during Insider Preview. If our - ISV - UWP App also have this feature, we can spent more time to trying the new feature, and Insider customer and testers can use it, and we could got feedbacks.

Hey guys,
it's extremely annoying when I face service issues with devcenter, with no knowledge if they are investigated or not.
I don't want all the time contact support, wait, wait, wait and "yeah we have issues", or now is just Saturday...I've to wait til Monday?

With service issue, I mean, devcenter backend is down or doesn't work properly in some ways.

Cam'on we need a service status page, with "we have issue, we're working on". At least we're not totally in the dark, in a limbo where we don't know if the issue is just a transient one or a serious one and we have to way days.