No, AFAICS, in Redhawk the whole framework is exposed as this way, and this is THE native way of calling methods, even if you are using C#.
Sure you have better language support as C# so you can do it more natually and properly, and with metadata in development time, but in the end you are calling other methods/assemblies as this, and your referenced assemblies are properly linked as implicitly imported DLLs, int the imports table, so Dependency Walker can see it. Also, all of the public methods in your assembly are exported as C functions as this.
But these function are not 'supposed' to be Reverse P/Invoke exports, they are actually Redhawk 'native' stuff, designed to be called from C#, so it suprised me that they are actually using native calling conventions and can actually be called from C++ and 'kinda' works.
Talking about Reverse P/Invoke, as Redhawk is supposed to unify the native and managed world, or at least much better interop, so yes, I can see there are also natual ways to do it in Redhawk.
One of the 2 user of Redawk in Win8 is whealogr.dll, and it is doing just that, and its exactly your scenario, as whealogr need to comply with the WDI 'plugin' interface, with is defined as C funtions like "WdiDiagnosticModuleMain/WdiGetDiagnosticModuleInterfaceVersion/WdiHandleInstance", so whealogr exports these 3 C functions, and internally they are just C# static methods in a class, exported directly, they have a call to 'RhpReversePInvoke()' in the begining, and a call to 'RhpReversePInvokeReturn' in the end, so these are 'really' Reverse P/Invoke functions, it wont suprise me that I can call those in C++.
plus: I noticed that there is an Attribute called System.Runtime.InteropServices.NativeCallableAttribute which MIGHT be related.
And, the other user of Redhawk is 'PowerWmiProvider.dll', and it exposes a COM interface, so I can see the team is using these 2 dlls to test the 2 main interop scenarios between Redhawk world and other parts of Windows.