А теперь филосовский вопрос.
1. Если ОС не позволяет записать неверные настройки в DCB, тогда сможем ли мы, когда либо получить такие же неверные настройки?
2. Если у меня есть driver к микросхеме, обладающей расширенными возможностями, тогда detectDefaultSettings мне наставит Unknown's. Как дальше быть?

Это я к тому, что от Unknown's надо как то избавляться. Получается, что мы вводим искуственные ограничения на те области, которые однозначно до конца не знаем. (А кто-то может и знает)

kuzulis, напиши с список что сделал все что было велено. Кстати, а кто третий разработчик?
Это вряд ли. В противном случае, драйвер данного устройства вообще не соответствует стандарту Windows. И, соответственно, не может быть использован. По хорошему, все дополнительные фишки должны быть реализованы так, чтобы они не препятствовали основной функции. Поэтому, скорее всего, unknown не будет нигде.

в логах гиториуса только ты и я? Или есть еще кто?

Тем самым вы обрезаете возможность узнать, а что же там было!
А вот для каких целей мне нужно знать то значение, это уже моё дело.

Тогда по порядку.
Rate - Можем ли отобразить пользователю начальное значение скорости? Можем. Пусть там да же будет сплошной хаос. Как-то это повлияет в дальнейшем? Возможно, но это проблема программиста, пишущего какое то решение. Зачем закрывать это поле UnknownRate-ом? И то только для одной платформы.
DataBits - пусть мы получим 9. И что? Ну скажет программист юзеру, что в настройках порта полная ересь. А дальше как хочет. Зачем тогда закрывать UnknownDataBits-ом?
Parity - вопрос несколько сложнее, надо посмотреть более детально.
StopBits - элементарный вопрос, для никсов 2 варианта, для винды - несколько больше  Почему бы не показать на форме значение отличное от 3х вариантов. Кому то плохо станет?
FlowControl - вот, пожалуй единственный аргумент в вашу пользу. Тут я не спорю.

Не буду конкретизировать. Выскажу свои соображения.
1. Отказаться от всех Unknown's. Причины уже описывались.
2. Так как нет Unknown's - не понадобятся методы detectDefaultSettings и им подобные.
3. Отказаться от сохранения и восстановления старых настроек. Оставить это на усмотрение другим программистам. Хотят сохранят, хотят востановят, это их дело. Или хотя бы предоставить возможность.
4. Предоставить возможность получать указатель на структуры типа DCB и пр. Вдруг комуто понадобится их детальный анализ.
5. Минимизировать использование дублирующих переменных, к примеру m_dataBits, для них и так уже выделена пямять.
6. Не инициализировать параметры в кострукторе. Их значения будут иметь смысл только после открытия порта.

Удачи с интеграцией в Qt.
 

1. не уверен, что для всех пунктов подойдет. Но можно рассмотреть такой вариант.
2. согласен с kuzulis
3. согласен с kuzulis
4. согласен с poru, пример реализации подобного можно найти в QWidget.
5. дублирования нет. я в свое время тоже хотел так, но при реализации не получилось.
6. начальная инициализация еще никому не повредила.

В любом случае, добавить новый метод можно всегда. А вот удалить...