This is a follow up to JDK-8289333
(see https://bugs.openjdk.org/browse/JDK-8289333?focusedCommentId=14513533&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14513533 )

Specificaition of method VaList::skip is still rather short

> Skips a number of elements with the given memory layouts, and advances this variable argument list's position.

It's not perfectly clear what would for example produce the following code

        try (var session = MemorySession.openConfined()) {
            VaList vaList = VaList.make(builder -> builder.addVarg(ValueLayout.JAVA_INT, 77)
                    .addVarg(ValueLayout.JAVA_LONG, -78),
                    session);
            vaList.skip(ValueLayout.JAVA_DOUBLE, ValueLayout.JAVA_BOOLEAN);
            System.out.println(vaList.nextVarg(ValueLayout.JAVA_INT));
        }


UPD: On MacOS aarch64 for pre-JDK20b08 the result is


Exception in thread "main" java.util.NoSuchElementException: No such element: i32
at java.base/jdk.internal.foreign.abi.SharedUtils.newVaListNSEE(SharedUtils.java:387)
at java.base/jdk.internal.foreign.abi.aarch64.macos.MacOsAArch64VaList.checkElement(MacOsAArch64VaList.java:152)
at java.base/jdk.internal.foreign.abi.aarch64.macos.MacOsAArch64VaList.read(MacOsAArch64VaList.java:122)
at java.base/jdk.internal.foreign.abi.aarch64.macos.MacOsAArch64VaList.read(MacOsAArch64VaList.java:93)
at java.base/jdk.internal.foreign.abi.aarch64.macos.MacOsAArch64VaList.nextVarg(MacOsAArch64VaList.java:68)

Specification
"Skips a number of elements with the given memory layouts"
leaves a space for interpretations of whether skipping with unmatching memory layouts would be successful or not.

The spec of ::skip might benefit from more detailed explanation or some references or hints or any "undefined behaviour" disclaimer.