13thконтрол спрятать, а вместо него показать другойпять раз перечитал и не понял, чем не устраивает Visibility

Я все равно не понял. Даже если бы это был бы не WPF. Есть задача скрыть один элемент и показать другой. Зачем их уничтожать-то? Уничтожатся, когда будет закрыта общая форма.

Roman MejtesShocker.Pro,

при этом еще и сам автор пишет, что на инициализацию уходит много времени. Тогда какой смысл делать её каждый раз?не, ну тут понятнее, инициализация может не понадобится вообще, если пользователь не щелкнул на кнопку "настройки". то есть при первом вызове создавать, а потом просто прятать

Ну то есть на ucDetails по любому тратится время при загрузке формы. А коли ucSettings быстрая, так и ее можно грузить сразу, а потом только переключать видимость (байндингом или триггерами)

Нормальная.

У-у-у, тут все запущено.
Начав работать с WPF нужно забыть все, чему научился, работая с Winforms, все подходы к работе с интерфейсом. Нужно изучить подход MVVM и начать мыслить его категориями (требуется, конечно, некоторое время и некоторая практика, чтобы набить руку).

Смысл в том, что у тебя есть ViewModel. Обработчик кнопки ничего не должен знать о том, что и как у тебя отображается. Он просто меняет во ViewModel-и какое-то свойство (например Mode (enum) или типа IsSettings (bool))
Сам же XAML привязан к этому свойству ViewModel-и. Конкретно Visibility нужных тебе объектов. Ему все равно, кто и зачем меняет это свойство, бизнес-логика представлению неинтересна. Оно просто реагирует на изменение свойств ViewModel-и.

Таким образом бизнес-логика работает сама по себе (не заморачиваясь визуализацией), представление работает само по себе (не заморачивась бизнес-логикой), связующее звено - VM

Не, необязательно, конечно. Можно пользоваться и как в WF - на событиях и прямом обращении к элементам.

Но, поверьте, стоит сразу привыкать к хорошему. Да, придется потратиться на изучение. Да, первичное создание простой программы занимает больше времени и усилий мозга на разработку VM, чем в Forms. Но потом какое удовольствие от того, что серьезные изменения функциональности приложения (и интерфейса в особенности) делаются легким движением руки, и первичные затраты усилий легко окупаются при развитии приложения.

Если же есть задача, сляпать что-то за пять минут, что не предполагает дальнейшего развития, можно и упростить себе задачу, не парясь правильной архитектурой.

По аналогии, можно быстро наляпать спагетти-код, решить проблему и забыть о ней. А можно посидеть с карандашом и листом бумаги и спроектировать многоуровневую архитектуру с независимыми слоями и тестами, которую будет потом легко сопровождать и развивать.