Expand on future possibilities a bit more

Author: retep998

text/0000-dll-kind.md

@@ -91,16 +91,14 @@ Delphi is a native language that has the ability to import symbols from dlls wit
 # Unresolved questions
 [unresolved]: #unresolved-questions
 
-* Bikeshedding on attribute names.
-* Should this feature be extended to other platforms?
+Whether there are any unresolved questions is an unresolved question.
 
 # Future possibilities
 [future-possibilities]: #future-possibilities
 
-With the features described in this RFC, we would be one step closer towards a fully standalone pure Rust target for Windows that does not rely on any external libraries (aside from the obvious and unavoidable runtime dependence on system libraries), allowing for easy installation and easy cross compilation.
-
-If that were to happen, we'd no longer need to pretend the pc-windows-gnu toolchain is standalone, and we'd be able to stop bundling MinGW bits entirely in favor of the user's own MinGW installation, thereby resolving a bunch of issues such as [rust-lang/rust#53454](https://github.com/rust-lang/rust/issues/53454).
-
-A future extension of this feature would be the ability to optionally lazily load such external functions, since Rust would naturally have all the information required to do so.
-
-Also users would stop complaining about having to install several gigabytes of VC++ just to link their Rust binaries.
+* With the features described in this RFC, we would be one step closer towards a fully standalone pure Rust target for Windows that does not rely on any external libraries (aside from the obvious and unavoidable runtime dependence on system libraries), allowing for easy installation and easy cross compilation.
+** If that were to happen, we'd no longer need to pretend the pc-windows-gnu toolchain is standalone, and we'd be able to stop bundling MinGW bits entirely in favor of the user's own MinGW installation, thereby resolving a bunch of issues such as [rust-lang/rust#53454](https://github.com/rust-lang/rust/issues/53454).
+** Also with that pure Rust target users would stop complaining about having to install several gigabytes of VC++ just to link their Rust binaries.
+* A future extension of this feature would be the ability to optionally lazily load such external functions, since Rust would naturally have all the information required to do so. This would allow users to use functions that may not exist, and be able to write fallback code for older versions.
+* Another future extension would be to extend this feature to support shared libraries on other platform, as they could also benefit from the ability to be more precise about linking. For example, on Linux and other platforms using ELF shared libraries, the compiler would emit an ELF `NEEDED` entry for the specified shared library name, and an undefined symbol for each function declared. (On ELF platforms, using the `link_ordinal` attribute would produce an error.) On such platforms, the `link_name` attribute may also specify a symbol name that includes a symbol version, including the `@@`.
+** Windows, however, should be the priority and figuring out details of support for other platforms should **not** block implementation and stabilization of this feature on Windows.