Rework future possibility re. macro invocations and mention vec![] there

text/3723-static-function-argument-unpacking.md

@@ -683,6 +683,14 @@ Notably, tuple structs can already be built with the adoption of argument unpack
 
 Prior work on designing such feature exists at least in the Rust Internals thread [Pre-RFC: Array expansion syntax](https://internals.rust-lang.org/t/pre-rfc-array-expansion-syntax/13490).
 
+## Unpacking Arguments for Macro Invocations
+
+Macros, callable with the `macro_name!(…)`, `macro_name![…]`, or `macro_name!{…}` syntax have been omitted from the scope of this proposal. The reason for omission is the time concerns related to doing the due diligence researching the design. For example, some macros (e.g. `println!`) accept an indefinite number of arguments.
+
+Unpacking tuples, tuple structs, and fixed-size arrays when invoking macros would probably make sense – after all, argument unpacking is only syntactic sugar for something that can be done already in the desugared form. For example, allowing unpacking within `vec![…]`'s brackets would, from a language user's perspective, add a missing piece to the work in [Unpacking in Fixed-Size Array and Tuple Literals](#unpacking-in-fixed-size-array-and-tuple-literals).
+
+Further design, meriting a separate RFC amending this one, is needed.
+
 ## Assigning Automatic Reference Status or Mutability
 
 Technically, during argument unpacking, it's possible to automatically assign varying degrees of (de)reference status or mutability such that code compiles. The following trivial code could most likely be inferred by the compiler in a way that it would compile successfully, for example:
@@ -706,10 +714,6 @@ fn main() {
 
 Further specification of automatically fitting argument unpacking to the reference or mutability status of the parameters in the function being called would merit a separate RFC.
 
-## Unpacking Arguments for Macro Invocations
-
-Macros, callable with the `macro_name!(...)` syntax have been omitted from the scope of this proposal. The only reason for omission is the time concerns related to doing the due diligence researching the differences in design. For example, some macros (e.g. `println!`) accept an indefinite number of arguments. Unpacking tuples, tuple structs, and fixed-size arrays probably would make sense – after all, argument unpacking is only syntactic sugar for something that can be done already in the desugared form. Further design, meriting a separate RFC amending this one, is needed.
-
 ## Unpacking Structs with Named Fields as Arguments
 
 Unpacking structs with named fields has been omitted as well. Although a design where the struct's field names are unpacked as the arguments, provided that the types are compatible, to the correspondingly named parameters could be considered, there are major concerns in this design related to API guarantees and the current lack thereof regarding function parameter naming: If a function in crate A is used such that at call-site, in crate B, its parameters are filled with arguments that were unpacked from correspondingly named struct fields, a **major** version bump would be required for crate A to prevent a Semantic Versioning violation in crate B from refusing to compile if parameter names in the function in crate A are changed. Currently, since the parameter names don't have an effect at the user's side, such change can be made with a patch version bump. Essentially, allowing name-based matching of struct fields to parameters would introduce parameter names as part of the public API of libraries.