Hi! As a long time WP7/8 and now W10M user, I noticed inconsistent behavior of opening flyout with touch versus mouse.
With mouse, flyout opens on right click which is ok. But when using touch gesture, I would expect behavior known from WP7/8 - flyout (aka context menu) should open after couple miliseconds while my finger is still touching the given item. Instead in W10M it opens just when I release the finger. This is very annoying as I never know if there is some additional menu under the item or not.

In the end, developers have to use some workarounds to simulate old behavior. You can see that even Apps list in W10M simulates old behavior instead of default one. Context menu appears while my finger is still touching the screen.

According to the documentation the proper way to handle input in a store app is to create a CoreIndependentInputSource from another thread by calling swapChainPanel.CreateCoreIndependentInputSource(). This gives you low latency input in case of a busy UI thread.

Once you create a CoreIndependentInputSource, touch visual feedback is visible again. Even if you disabled it using
auto pointerVisualizationSettings = Windows::UI::Input::PointerVisualizationSettings::GetForCurrentView();
pointerVisualizationSettings->IsContactFeedbackEnabled = false;
pointerVisualizationSettings->IsBarrelButtonFeedbackEnabled = false;
It's not about aesthetics, Visualfeedback kills performance, the framerate in games drops by half, which is ironic if you think that's the kind of apps CoreIndependentInputSource was created for in the first place. Devices with touch input are the ones that suffer the most from this bug since they come with weak GPUs. Devs have to chose either low responsiveness or low performance.

CoreIndependentInputSource has it's own Dispatcher, does that mean it has it's own HWND/message queue?
Maybe that's the cause of the bug, PointerVisualizationSettings.GetForCurrentView() is tied to the main Window.
If you try to call "PointerVisualizationSettings.GetForCurrentView().IsContactFeedbackEnabled = false;" from the input thread it fails with an exception.

I got the _hWnd from CoreIndependentInputSource.Dispacher using the VS debug inspector and then called TryDisableWindowsVisualFeedback() as seen here http://stackoverflow.com/questions/27550373/disable-touch-visual-feedback-on-windows-8-1-programmatically-desktop-app
The visual feedback was disabled!
However, live code has no access to that hWnd. All helpful Win32 apis fail one way or another (GetActiveWindow(), GetProccessId(), EnumWindows(), etc).

Why do you always have to make a developer's life difficult.
There's no easy way to detect Left Control key pushes.

Because on international keyboards, if Right Alt is pressed, then Left Control is also pressed? Why oh why, this is the stupidest thing ever.

I thought when designing a new API you could get rid of all the ******** and just make things clean and simple.

So I've developed a work around, to detect key pushes for LeftCtrl and RightAlt, and if both are pressed at the same time, then LeftCtrl pushes are ignored.

void OnKeyDown(CoreWindow^ sender, KeyEventArgs^ args) // mouse buttons are not passed here
{
KB_KEY key=KB_KEY(args->VirtualKey);
switch(key)
{
case KB_CTRL: if(!args->KeyStatus.IsExtendedKey){Kb._special++; return;} break; // because this can be triggered by pressing RightAlt too, we need to record this event, and if RightAlt is pressed in the same frame, than cancel this, there's no other way, because holding RightAlt results in 'GetKeyState' being on for left ctrl too
case KB_ALT : if( args->KeyStatus.IsExtendedKey) Kb._special--; break;

And later I check if(Kb._special>0)

But that doesn't work too, because now it turns out, that if I press just RightAlt, then I can get callbacks for LeftCtrl and RightAlt happening in different frames.

OnKeyDown with LeftCtrl gets called in frame 10
OnKeyDown with RightAlt gets called in frame 11

Why can't you just make it easy and get rid of AltGr altogether.

Waiting for reply.