My preference would be:

(prev) fn clean_obsolete_record(%{id: 31}), do: ...
(current) fn clean_obsolete_record(%{id: 31, vsn: 2}), do: ...
(next) fn clean_obsolete_record(%{id: 31, vsn: 3}), do: ...

This makes it clear from a data perspective which function would execute. If you happen to store the function argument in a database or have to replay the data there is a clear indicator which function would execute.

YMMV

I prefer this approach. this pattern is not really new in Elixir when you need to control flow.
There is a pattern called Token:

Which fits nicely into this. Basically a Token contains all the information of your request and workflow, and it allows you to pattern match on versions like you are doing.

@tty Thanks. It would work too, since the pattern matching also compares parameters. What I’m thinking about is fn clean_obsolete_record(general_args, vsn: vsn), do: ... which separates general_args with a predefined vsn parameter. vsn can be overwritten If they are mingled in the collection. Also this approach enforces versioning to the developers.

@Fl4m3Ph03n1x Thanks. I understand that the tokening in the link page is one good example of pattern matching. (Pattern matching is so useful and make the codes cleaner than when guard.) For me, the original idea was kinda API versioning commonly used in API endpoint.

Versioning APIs will provide backward compatibility and eliminate deprecation problems significantly and easily.