Apply suggestions from code review

Co-authored-by: Chandler Carruth <[email protected]>

proposals/p3980.md

@@ -88,8 +88,8 @@ Here, the return types of `F` differ.
 
 This proposal aims to address the differing return types by unifying the type of
 `C` regardless of whether it's `extern`. This could be done under multiple
-different approaches, and this proposal aims for one which is efficient to
-process.
+different approaches, and this proposal aims for one which enables efficient
+implementation strategies.
 
 ## Background
 
@@ -389,12 +389,13 @@ fn Make() -> MyType*;
 ```
 
 ```
-package Other library "extern" api;
+package Other library "extern";
 extern library "type" class MyType;
 ```
 
 ```
 package Other library "use_extern";
+import library "extern";
 fn Print(val: MyType*);
 ```
 
@@ -605,10 +606,12 @@ discussed other syntaxes for `extern` + `extern library`. These were mainly
 `has_extern`/`is_extern`/`externed` + `extern`. The current syntax is more
 verbose, but was chosen because:
 
--   The behavior of imports being incomplete was something leads wanted to offer
-    separate from the non-owning declaration, and `extern` was decided to be a
-    good name for that.
--   It has extra detail in `extern library "<owning_library>"`.
+-   Providing behavior of imports being incomplete orthogonally but using the same keyword allowed us have a single meaning for the `export` keyword and consistent usage of it on declarations.
+    -   Enabling this behavior independently wasn't seen as a problem by the leads and potentially useful even if not the primary motivation. The primary motivation was orthogonality of features.
+    -   Within this context `extern` seemed like an acceptable name, and alternative names seemed significantly less good. It also gives us only one new keyword.
+-   Adding the owning library with `extern library "<owning_library"` will hopefully give us better diagnostics, better human readability and understandability of the code.
+    -   It is _very_ verbose, but this verbosity goes on the forward declaration in the non-owning library, which we expect to be read less often.
+    -   And if in practice we find the verbosity becomes a significant issue we can revisit syntaxes to address that specifically. For example, if we have significant repetiton, we might consider a grouping structure such as `extern library "..." { <many forward declarations> }`.
 
 ### Have types with `extern` members re-export them