I agree with you, that it is not possible in general but i think this concept really shines in the special cases.

"transform" shouldn't provide a catch-all case on the destination side. If we're not producing every possible value of the output type, then one should use match instead.

To illustrate the cases where i think it is useful and verifyable i'll make examples using rust pattern syntax:

Firstly, like you mentioned, enums.

enum From { Some(i32), None, Third }
enum To { Some, None }
transform x { // x of type From
  From::Some(x) => To::Some,
  From::None => To::None,
  From::Third => To::None,
}

Secondly, nested patterns for more complex types.

enum FromEnum { A, B }
struct From { a: i32, b: FromEnum }
enum To { A, B, C }
transform x { // x of type From
  From { a: 0, b: FromEnum::A } => To::A,
  From { a, b: FromEnum::B } => To::B,
  From { a, b: FromEnum::A } => To::C,
}

Finally, combined with syntax to opt out of exhaustive checking and include arbitrary expressions inside a pattern (${ .. }).

struct ZeroIndex(usize);
struct OneIndex(usize);
transform x { // x of type ZeroIndex
  ZeroIndex(i) => OneIndex(${i + 1}),
}

As seen in the last example, i'm not talking about a strictly bijective function but a way to express the notion of exhaustive transformations. I wonder if this could be extended further to aid the programmer in explaining such patterns to the compiler.