update load workflow

RFCs/FS-1027-fsi-references.md

@@ -114,25 +114,23 @@ Behavior should not be so different at runtime.  When executing code interactive
 
 When launching FSI with a script using one of the new `#r` references, FSI will do the following:
 
-1. Check if each dependency exists in the known place for the specified tool.  If it does, `#r` that dependency when executing FSI.
-2. If a dependency does not exist, search for the tool in a known/blessed area.  Error out if it can't be found.
-3. Call out to the tool to resolve dependencies.
-4. `#r` the resolved dependencies in an ephemeral script (or the script generated by Paket if using Paket).
-5. `#load` that script into the FSI session, thus giving it the references it needs to execute.
+1. Check which tools is registered for a given #r prefix.  Error out if no tool can't be found.
+2. Let the tool check if each dependency exists in the known place for the specified tool or otherwise the the tool resolve all dependencies.
+3. `#r` the resolved dependencies in an ephemeral script (or the script generated by Paket if using Paket).
+4. `#load` that script into the FSI session, thus giving it the references it needs to execute.
 
 ### Running a script in an active FSI session
 
 This scenario is as follows: I have launched FSI at some point, and now I wish to execute a script which may or may not have references that I already have loaded into FSI.  The behavior should actually be the same as if FSI were launched with the script:
 
-1. Check if each dependency to be loaded exists in the known place for the specified tool.  If it does, `#r` that dependency when executing FSI.
-2. If a dependency does not exist, search for the tool in a known/blessed area.  Error out if it can't be found.
-3. Call out to the tool to resolve dependencies.
-4. `#r` the resolved dependencies in an ephemeral script (or the script generated by Paket if using Paket).  Check version numbers against what we already have loaded in the FSI session.  If any `.dll` names and versions match, don't `#r` them into the script.
-5. `#load` that script into the FSI session, thus giving it the references it needs to execute.
+1. Check which tools is registered for a given #r prefix.  Error out if no tool can't be found.
+2. Call out to the tool to resolve dependencies.
+3. `#r` the resolved dependencies in an ephemeral script (or the script generated by Paket if using Paket).  Check version numbers against what we already have loaded in the FSI session.  If any `.dll` names and versions match, don't `#r` them into the script.
+4. `#load` that script into the FSI session, thus giving it the references it needs to execute.
 
 This is because:
 
-1. A reference may already be loaded for the current FSI session, but a differen version was specified in that script.  We need to allow that to error out, because the script code may depend on a higher or lower version than what is already loaded.  That could cause a runtime error if we just allowed it to run on whatever we had already loaded.
+1. A reference may already be loaded for the current FSI session, but a different version was specified in that script.  We need to allow that to error out, because the script code may depend on a higher or lower version than what is already loaded.  That could cause a runtime error if we just allowed it to run on whatever we had already loaded.
 2. It's too complicated to attempt to only partially load stuff if something is already referenced.
 
 ### Referencing a new dependency in an active FSI session