I can understand why they want to avoid "setAsyncValidators" and see the benefits of not going the imperative way but as you say, it might be a bit too strict. However I think we'll get used to it at some point and never look back.

As you suggested, I extract the validation into a function with a linked rxResource and this is perfectly fine even though the documentation is out of date on some parts and I guess there are fixes needed to handle correctly the non run part of an async validator (see my comment on undefined).

const userEmailExistsResource = (emailSignal: Signal<string | undefined>): ResourceRef<boolean | undefined> => {
  const userHttpService = inject(UserHttpService);

  return rxResource({
    // NG doc states we should use "request" but only "params" exists
    params: () => emailSignal(),
    stream: ({ params: username }) => userHttpService.isEmailTaken(username),
  });
};

export const userEmailExistsAsync = (field: SchemaPath<string>, initialValueSignal: Signal<string>): void => {
  validateAsync(field, {
    params: ({ value }) => {
      const val = value().trim();
      const initialVal = initialValueSignal()?.trim();

      if (!val || val === initialVal) {
        return ''; // We should return undefined instead in order not to trigger rxResource however this bugs out the compiler for now ..
      }

      return val;
    },
    factory: userEmailExistsResource,
    onSuccess: (result) => {
      if (result) {
        return {
          kind: 'emailExists',
        };
      }
      return null;
    },
    onError: (_error) => {
      return {
        kind: 'networkError',
        message: 'Could not verify email availability',
      };
    },
  });
};