Different foreground value is applied to elements, which are present inside RadBusyIndicator when using the Office2019 theme.

To work this around, set a new value to the Foreground property of the RadBusyIndicator control.

Using the Fluent theme with a higher DPI, e.g. 125%, the spinner ellipses of the BusyIndicator appear cut off on the top and bottom when a higher DPI is used and the control is hosted in the DocumentHost of a RadDocking instance.

Missing biding to Foreground in the ContentPresenter of the control which prevents not styled controls (i.e. TextBlock) not to receive the proper Foreground for the current theme.

Workaround:

add Foreground = "{TemplateBinding Foreground}" to the ContentControl in the ControlTemplate for RadBusyIndicator.

Scheduled for: 
The fix for this issue will be available with LIB (version 2018.3.1203) published on Monday, 3-rd December, 2018. 
 

Available in LIB version 2016.3.1017, it will be also available in the 2016 R3 SP1 release. 

It would be great if the details of the animation weren't tied to the theme. For example, if you want the "parading dots" motif, you have to go with Windows8, Windows8Touch, or one of the "2013" themes. 

The control should have an "AnimationStyle" enumeration property, where you can select which animation you want, independent of the theme. Even better, it would be great if you could specify your own animation.

Thanks!

Available in LIB version 2015.2.810, it will be also available in the 2015 Q3.

If the IsEnabled property of a control placed inside the BusyIndicator is bound TwoWay and has NotifyPropertyChanged, in non debugging the property stays to False.

If you change the Culture at run-time and reload the control, the new culture doesn't apply.

If Hyperlink are placed in the content of the control while the IsBusy is set to true, those links are disabled.

Setting the Foreground property applies only to the BusyContent rather then the other content inside the control.

The title is accurate but the description is pretty far off. The problem is that a RadBusyIndicator with a DisplayAfter of 1.5 seconds and IsBusy=true  will initially set its contents to disabled and then enable the contents when IsBusy becomes false.  The

RadBusyIndicator throw error when theme is Metro and is not set as an Application theme. Message=Cannot access Freezable 'System.Windows.Media.SolidColorBrush' across threads because it cannot be frozen.
Workaround:
Whenever you are running metro styled telerik components you must invoke:
MetroColors.PaletteInstance.Freeze();
So the shared color resources we bind our controls to could be frozen and become thread safe. The above line could be placed in the OnStartup in your example and it would work.

Available in LIB version 2015.3.1207,  it will be also available in the 2016 Q1 release.

please test again and add steps to reproduce