docs: add informal findings about wing328's test case

Documented the real-world implications of the anyOf fix by showing:
- How the old generator would produce duplicate enum variants (broken Rust code)
- Why wing328's test case perfectly demonstrates the problem
- The practical difference between treating anyOf as choice vs composition

These findings emerged from merging PR OpenAPITools#21911 and seeing firsthand how
the old behavior would literally generate uncompilable code for certain
anyOf schemas.

Author: timvw

docs/anyof-vs-oneof-true-semantics.md

@@ -314,6 +314,28 @@ Your understanding is correct:
 - **anyOf** = "You can be ANY combination of these things"
 - **oneOf** = "You must be EXACTLY ONE of these things"
 
+## Real-World Bug Example
+
+Just discovered this while working with wing328's test case. The old Rust generator would literally generate broken code for this anyOf:
+
+```yaml
+ModelIdentifier:
+  anyOf:
+    - type: string
+    - type: string
+      enum: [gpt-4, gpt-3.5-turbo]
+```
+
+Old generator output:
+```rust
+pub enum ModelIdentifier {
+    String(String),  // Variant 1
+    String(String),  // Variant 2 - DUPLICATE NAME! Won't compile!
+}
+```
+
+This is what happens when you treat anyOf (composition) as oneOf (choice) - you get nonsensical code. The correct approach generates a struct where both can coexist.
+
 ## Conclusion
 
 You're absolutely right:

docs/rust-oneof-anyof-semantics.md

@@ -403,4 +403,67 @@ Previously, the Rust generator treated `anyOf` the same as `oneOf`, generating e
 To migrate existing code:
 - Replace enum pattern matching with struct field access
 - Use the `validate_any_of()` method to ensure at least one field is set
-- Access individual options via the `as_*` fields
+- Access individual options via the `as_*` fields
+
+## Real Example: Wing328's Test Case
+
+I merged wing328's PR #21911 which has a perfect test case showing the difference. Let me walk you through what I found:
+
+### The Test Schema
+Wing328 created this anyOf schema:
+```yaml
+ModelIdentifier:
+  description: Model identifier that can be a string or specific enum value
+  anyOf:
+    - type: string
+      description: Any model name as string
+    - type: string
+      enum: [gpt-4, gpt-3.5-turbo, dall-e-3]
+      description: Known model enum values
+```
+
+### What the Old Generator Would Produce
+With the old (wrong) behavior, this would generate:
+```rust
+// OLD: Incorrectly treats anyOf as oneOf
+#[derive(Clone, Debug, PartialEq, Serialize, Deserialize)]
+#[serde(untagged)]
+pub enum ModelIdentifier {
+    String(String),  // First string option
+    String(String),  // Second string option - DUPLICATE! This is broken!
+}
+```
+
+See the problem? We'd have duplicate enum variants! The generator would actually produce invalid Rust code. Plus, even if it worked, you could only choose ONE option, not both.
+
+### What Our New Generator Produces
+With the correct anyOf implementation:
+```rust
+// NEW: Correctly treats anyOf as composition
+#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
+pub struct ModelIdentifier {
+    #[serde(skip_serializing_if = "Option::is_none", rename = "as_any_of_0")]
+    pub as_any_of_0: Option<String>,  // Any model name
+    
+    #[serde(skip_serializing_if = "Option::is_none", rename = "as_any_of_1")]
+    pub as_any_of_1: Option<String>,  // Known enum values
+}
+```
+
+Now both fields can be set! This is actually useful - imagine an API that accepts both a freeform model name AND validates against known models. With anyOf, you can validate against both schemas simultaneously.
+
+### Another Example from Wing328's Tests
+He also included this more complex anyOf:
+```yaml
+AnotherAnyOfTest:
+  anyOf:
+    - type: string
+    - type: integer
+    - type: array
+      items:
+        type: string
+```
+
+Old behavior would force you to choose: "Is this a string OR an integer OR an array?"
+
+New behavior lets you have all three! Maybe it's a weird API, but that's what anyOf means - the data can match multiple schemas at once. The generator shouldn't make assumptions about what's "sensible" - it should implement the spec correctly.