I notice that vulkan-loader contains a vendored copy of vulkan-headers,
in order to keep the library and headers in sync, with the "upstream"
tarball actually being composed by repacking the combination of
vulkan-loader and vulkan-headers.

Since it's a 3.0 (quilt) package already, and the vendored vulkan-headers
is in the top-level directory, this seems like a perfect fit for multiple
.orig tarballs:

- download https://github.com/KhronosGroup/Vulkan-Loader/archive/sdk-1.2.131.2.tar.gz
  and rename it to vulkan-loader_1.2.131.2.orig.tar.gz
- download https://github.com/KhronosGroup/Vulkan-Headers/archive/sdk-1.2.131.1.tar.gz
  and rename it to vulkan-loader_1.2.131.2.orig-vulkan-headers.tar.gz
  (note the version number mismatch - sorry, I think this is unavoidable
  with current tools, if your upstream doesn't always keep the version
  numbers in sync)
- put both in ../ or wherever else you keep your upstream tarballs, or
  commit them to pristine-tar with gbp import-orig if you use that
- import them both into your upstream-unstable git branch, perhaps with
  gbp import-orig --upstream-vcs-tag=... --component=vulkan-headers
  to keep it as a descendant of the upstream git history

This would avoid needing to repack the upstream tarball, which seems likely
to be problematic if more than one developer imports it independently.

The yquake2 source package in contrib is an example of this technique.
I use DEP-14 branch names rather than the xorg-team's conventions, but
I think the difference is mostly just labelling? In particular,
"component=ctf" in debian/gbp.conf and debian/watch (in your case it
would be "component=vulkan-headers") activates the support for multiple
.orig tarballs in gbp and uscan.

I'm involved in the maintenance of a derivative (the Steam Runtime) that
has an interest in having the latest Vulkan library, and it's looking like
I might need to package the latest release (a development version "v...",
rather than the stable "sdk-..." versions that you package). Would you
be interested in receiving a merge request with that version, targeting
experimental?

Thanks,
    smcv

Hmm, well it seems that using multiple tarballs involves more steps than
the current one, if the tags can get out-of-sync as they are now.. so
right now I'd rather keep the current method.

sdk-* tags are needed in order to get the full stack to build, v.. tags
don't guarantee that they all fit together. So in that sense, having
only the loader and maybe tools (and not validationlayers) in
experimental, tracking v.. tags is fine by me. But I'd rather have you
then handle those all the way ;)

I asked you to consider it, you considered it, and the answer was no,
so: closing this.

    smcv