I put some comments on the code. But I have some overall notes.

First of all, I'm a little uneasy with the change. There are at least 3 comments about hacks in this change, which kinda makes me uncomfortable. But I'm a lenient person, so I'm okay giving all of them a pass. I'm just uncomfortable because I'm not fully mastering this topic, or even the bug it's trying to fix.

However, this doesn't break backward compatibility. So I'm strongly considering approving this change.

Even though I don't know yet, there are some things that need to be addressed if you want me be able to merge it.

1. Please make only one commit. I don't mind multiple commits on changes. But I hate clean up commits. I know this repo has many from me, but as the owner of the repo, I have the right to break my own rules 😄 . I just don't like it when other don't follow my rules 😛 . For this change, I would like to ask you to make only one commit please, because I think it fits nicely into one.
2. Please rebase onto the master branch, as I've said in one of the comments, the tests were failing when you forked it, and I fixed them ~1h ago. I want the CI to be green before merging this change. It is currently green on master, if it becomes red again, no need to fix it, I'll fix it again. We're regularly running master against the latest clippy, so when clippy adds new checks, it breaks once in a while.
3. Please use git commit -s as mentionned in the README. This means that you signed off the Developer Certificate of Origin. See more information in my comment about it

Thank you for your patch, with a nice test 🙂 .

I looked at it. I'm not gonna lie, it's not my favorite change, but I think it's fine.

I would like to ask you to fix the comment from Mingun (I commented on it). Other than that I think we're good to go. 👍

Thanks for your contribution 🙂

I accidentally send two comments without starting review.

My main concern here that this changes is not described in the code, how they are worked and why in that way.

I understood that you've represent tagged YAML values as maps and use visit_map when deserializing value is serde's Content, but it is not quite clear why it is needed to call visit_map for that? Why visit_enum does not work or why we cannot use visit_map in all cases?

Ok, let me summarize what the problem this PR fixes.

We have a structure with enum field a, and enum { A, B, C(String) }. The values of such string are represented in YAML as (here I use an array of 4 items to show each variant):

- a: !A # Inner { a: Enum::A }
- a: !B # Inner { a: Enum::B }
- a: !C # Inner { a: Enum::C("") }
- a: !C inner string # Inner { a: Enum::C("inner string") }

The tags (!Thing) is a thing where representation in JSON and YAML are differs. The JSON equivalent representation would be

- a: A # Inner { a: Enum::A }
- a: B # Inner { a: Enum::B }
- a: { C: null } # Inner { a: Enum::C("") }
- a: { C: "inner string" } # Inner { a: Enum::C("inner string") }

or using only canonical YAML syntax

- a: A # Inner { a: Enum::A }
- a: B # Inner { a: Enum::B }
- a:   # Inner { a: Enum::C("") }
    C:
- a:   # Inner { a: Enum::C("inner string") }
    C: inner string

Deserialization of Enum type involves calling Deserializer::deserialize_enum which is DeserializerFromEvents::deserialize_enum when we deserialize from yaml deserializer.

Now we want to flatten our struct type into another type:

#[derive(Deserialize, PartialEq, Debug)]
struct Outer {
  #[serde(flatten)]
  inner: Inner,
}

but due to #[serde(flatten)] deserialization code buffers all content into internal Content type. That buffering disrupts many formats, because then types are deserialized from that buffer using generic ContentDeserializer or ContentRefDeserializer which are not aware of the special handling in some formats. That is what serde-rs/serde#1183 about.

Bufferization is performed by calling Deserializer::deserialize_any which is DeserializerFromEvents::deserialize_any. Content is created by using ContentVisitor which does not support Visitor::visit_enum. YAML deserializer uses visit_enum in deserialize_any and therefore gets error (note, that using it in deserialize_enum is fine because this method not called when deserialize into Content).

The fix detects when we trying to deserialize into Content (is_serde_content variable) and replaces visit_enum by visit_map. The serde_json never suffers from that, because it never calls visit_enum in deserialize_any.

Because now we sometimes call visit_map instead of visit_enum, we implement MapAccess for EnumAccess. The new flag has_visited tracks if we already deserialized the key or not, in order to our map represent one-entry map.

I would rename and maybe remove some fields and change comments according to the description above (I left individual comments), but in other aspects I think it can be merged.