I have a good bit of experience here so I’ll try to lend what advice I can.
Also sorry this is such a long response. Or maybe that’s what you were hoping for 
1.A) Procedural mesh generation/manipulation is possible. Both engines have rather similar pipelines for it so no huge difference in difficulty. Xenko has you define a struct Type for the vertex to contain whatever data you want per vertex (normal, color, texture, etc) whereas Unity uses separate arrays for each data component.
1.B) Xenko gives you direct access to the low level buffers used to send mesh data to the GPU. This is good because it allows you to reuse those large arrays and reduce GC pressure, but it can be tricky to decipher how that low level API works and to use it correctly. Unity doesn’t let you do this, which makes it simpler but causes GC problems. However, I did recently discover that they have SetVertices/SetColors/Set[T] methods that take List parameters containing the data. I suspect those methods are actually meant to let you do something similar to reusing the buffers. IE make a List with a large initial capacity, fill it with data, use the SetWhatever method, clear the List (but don’t call Trim!) and then you can fill it with data again for another mesh, thus avoiding GC by not having to constantly make new arrays. I haven’t actually tried this though so I might be horribly wrong. Unfortunately their documentation on these methods is awful.
1.C) You can use vertex colors. You can see such working on my Project Voxelscape post / right here; https://www.youtube.com/watch?v=whJOtux2DrQ. Technically it’s supposed to have some pixel textures too, but I didn’t get both vertex coloring and textures working in the shader. Should absolutely be doable though, I just can’t write shaders >.<
2.) Never resolved / can’t do it. BulletSharp has a type that should be appropriate for it but it is not supported by Xenko. You would either have to implement said type yourself and hope the Xenko team accepts your pull request or ditch their physics engine entirely and try integrating something like BulletSharp or BEPUphysics yourself. On the other hand, I did some testing with Unity3D and it looks like they do support accurate physics collisions against procedural meshes, with some caveats of course. You can do physics of simple primitives against a non-convex mesh, but you can’t do non-convex to non-convex. IE you can have a player/creatures whose collision is a simple capsule and some crates you can push around and those sorts of things can collide with the environment, but you couldn’t have 2 proc gen’d meshes collide accurately like say 2 large spaceships. You’d need to use some other trick to simplify the collision.
3.) Got nothing here for Xenko or Unity. Been working on implementing my own LOD system where the mesh generation system and produce simpler meshes for LODs.
4.) Also not a lot to say. Both engines support real time lighting with dynamic shadows, both cast by and onto procedural generated meshes. Pretty awesome not having to implement a Minecraft lighting engine lol.
5.) Xenko has it’s own special flavor of shaders where you compose them out of different smaller pieces of shaders. Looks like Unity3D moved to some sort of Standard Shader model as well to make it easier. As mentioned before though I can’t shader so ¯_(ツ)_/¯
6.) Yes, but I’ve only figured out how to make it either do lighting + vertex colors or lighting + texture. I’d like to do all 3 together, but in a rather particular way… Pretty sure it can be done, but… shaders…
7.) Xenko has a built in notion of an AsyncScript. As I understand it it lets you call into async code and then when you need to get back onto the main thread you can just await Script.NextFrame() and it’ll marshall you back into the main loop. Super easy to use. Beyond that the engine has some built in multi-threading to help improve performance, but if you’re doing any really stressful work like say generating a bunch of voxels or procedural meshes you’ll likely want to do that on background threads yourself. Similar restrictions apply in Xenko like they do in Unity, such as not being able to modify game objects on background threads. That’s just an inherent limitations of just about any UI framework / game engine. The big benefit of Xenko though is that it’s modern C#, meaning you can uses Tasks, async await, TPL Dataflow, Reactive Extensions, Concurrent collections, Immutable collections, all sorts of amazing stuff. Being stuck to C# 3.5 in Unity was awful for multi-threading…
This reply has gone on plenty long already soo maybe write back if you wanna hear more about anything in particular.
