Using Option<Option> or another type e.g. enum { Value(T), Null, Unset } will add extra overhead to the struct and may limit its usability.

Can you please clarify what exactly you mean here? Have you any numbers proofing this claim? Otherwise I would say that this theoretical overhead is not measurable in practice, therefore I do not see any reason why this should be changed.

Let me know if you have any other workarounds other than manually implementing AsChangeset.

Just to clarify that: Implementing AsChangeset manually is not considered to be a workaround, that's something that is a valid use case. The derive is on purpose designed in such a way that is covers simple conversions well, but anything more involved not.

Sorry for the ambiguity.

Let's say we have a update struct

struct A {
  ...
  field: T
  ...
}

I would like to make T::Null set the field NULL, and T::Skip skips the field, but there is no way to make a custom variable T parsed as Null except I manually implement AsChangset for struct A, though other fields are fine with the derive macro. Implementing AsChangeset for T will not work, as the Option unwrapping logic is built in the derive macro.

There do have other workarounds, but it should be more convenient if a conversion function can be added for that field.

Have you tried to just implement AsChangeset for T? The derive internally calls the AsChangeset impl for every separate member, as far as I'm aware. That's in my opinion the correct place to handle this.

What the derive macro does internally is to generate the following code

struct A {
  ...
  field: T,
  field2: Option<U>,
  ...
}

impl AsChangeset for A {
  fn as_changeset(&self) -> Self::Changeset {
    (
      ...,
      table::field.eq(self.field),
      self.field2.map(|x| table::field2.eq(x)),
      ...,
    ).as_changeset()
  }
}

Using a user-defined struct will not work as Self::as_changeset() is called after Eq::<Left, Right>(table::field, field, where there is a constraint AppearsOnTable<Right> which will never be met.

That sounds like something that should be fixed in the derive itself. I would accept a PR doing that. (The Insertable derive already does something like that, so maybe look there for an implementation idea?)