Steps to reproduce

#175090 and PR #176711 does break current implementation, since: 3.39.0-0.1.pre

An example can be found here:
#176711 (comment)

Further the type safe part of #175090 (in my opinion) does raise more problems than it actually solves. I personally don't see removing the ambiguity has any real world scenarios. In contrast the need of a null value is actually used. I don't see a concrete issue with getting the same value can result from two different events does have a negative impact (why would someone want to differentiate that, and also with this change there is not even a built-in option to differentiate.

Expected results

To either:

• Revert
• Not break the current implementations, e.g. Make DropdownMenu generic type non nullable #176711 (comment)
• Write a migration guide or in the docs how to circumvent the lack of using null as value (Make DropdownMenu generic type non nullable #176711 (comment)) (least preferred)

Actual results

The changes are breaking the below example and are a valid approach to reflect empty selection: https://material-web.dev/components/select/#usage

There are already three cases which were mentioned to break (myself included).

Code sample

import 'package:flutter/material.dart';

void main() => runApp(const MyApp());

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return const MaterialApp(
      title: 'Flutter Demo',
      home: Card(
        child: DropdownMenu<String?>(
          dropdownMenuEntries: [
            DropdownMenuEntry(value: null, label: 'Label'),
            DropdownMenuEntry(value: '1', label: '1'),
            DropdownMenuEntry(value: '2', label: '2'),
          ],
        ),
      ),
    );
  }
}

Screenshots or Video

Logs

[Paste your logs here]

Flutter Doctor output

[Paste your output here]