RFC for PowerShell Core Interop Module

Author: DarwinJS

1-Draft/RFCXXXX-PowerShell-Core-Interop-Module.md

@@ -1,11 +1,16 @@
 
-
 RFC: RFC<four digit unique incrementing number - assigned by Committee>
+
 Author: Darwin Sanoy
+
 Status: Draft
+
 SupercededBy:
+
 Version: 0.1
+
 Area: Standard Modules
+
 Comments Due: 5/1/2017
 ---
 
@@ -17,35 +22,43 @@ I have written serveral debugging scripts which also run, unmodified, on Linux o
 
 I have learned serveral fixups that go a long way to making things work without changing the code.  For example, creating $env:temp and pointing it to /tmp on Linux.
 
-I know that some will think that this support should be bi-directional - but I personally feel that the adoption of PowerShell on Linux will most likely be 
+I personally feel that the adoption of PowerShell on Linux will most likely be 
 driven by those who know PowerShell well on Windows and want to use it to manage Linux.  I think it will be quite a while before there is much traction to
 go the other direction (start learning PowerShell on Linux, get proficient, start using it to manage Windows).  It is also a little more challenging to go the other
-was as Linux does not rely on as many environment variables to point to platform-wide standard paths.  (e.g. /tmp folder)  However, if it should be addressed up front, it 
-would seem to make sense if this module had a neutral name and did fix ups in both directions.
+was as Linux does not rely on as many environment variables to point to platform-wide standard paths.  (e.g. /tmp folder)  
+
+
+I have addressed the issue as bi-directional in this RFC, but would be quick to back off to Dev on Windows => Run on Linux if the other way seems not worth the effort.
+If both directions were desirable upfront, it would seem to make sense if this module had a neutral name and did fix ups in both directions - 
+unless that would make the code too complex - then perhaps a module per "interop direction".
 
 I also want to full acknowledge that this type of support is not appropriate to compile right into the PowerShell code itself - as it would seem to then be attempting 
 to "windowize" the Linux platform and would be confusing for Linux professionals and organizations who might adopt PowerShell to manage pure Linux environments.
 
 ## Motivation
 
     As an administrator who wishes to start managing Linux with PowerShell,
-    I can port Windows scripts, snippets and modules that contain popular Windows references (usually environment variables) to Linux without changing every reference
-    so that I can save work by reuse as much of my Windows PowerShell code as possible, and where desirable, create scripts that run on both Windows and Linux unmodified.
+    (or vice versa) I can port scripts, snippets and modules that that contain 
+    popular references on my initial development platform (eg environment variables) 
+    to the other platform without changing every reference, so that I can save work 
+    by reusing as much of my initial platform PowerShell code as possible, and 
+    where desirable, create scripts that run on both Windows and Linux unmodified.
 
 ## Specification
 
 - Standard shipped-with PowerShell Core module
 - Written as a script
-- That "fixes up" a Linux environment
-- with common Windows standard pointers
-- or code samples for common things that need to be done
+- That "fixes up" a target environment (Windows or PowerShell)
+- with common standard pointers 
+- or code samples for common things that need to be done from the "developed on" platform
 - including code samples of methods that simply work on both platforms unchanged
 - that requires some action from an administrator to enable (e.g. run a CMDLet in their script or a machine based profile)
 
 ###example
 Only tested on CentOS - so may need improvement for other distros
 
-~~~~
+~~~~PowerShell
+#Code that adapts Windows PowerShell to Linux
 $RunningOnWindows = $true
 If ((Test-Path variable:IsWindows) -AND !$IsWindows)
 {