Thanks for the suggestion. In general we're pushing developers towards x:Bind functions, which is more flexible and requires less code.

Additionally, with regards to standard XAML development, we encourage developers to read the Microsoft documentation first, which explains those topics in details.

1. x:Bind

I did understand it as if it is outdated to use and Binding is the way to do, because of the caption in documenation to that:

Uno Support for x:Bind
Uno supports the x:Bind WinUI feature, which gives the ability to:

bind to normal fields and properties
static classes fields
functions with multiple parameters
events
x:Bind on "Plain-old C# Objects" (POCO) created in XAML

e.g. if I tell

x:Bind local:MainModel.Title, Mode=OneWay

It do tell that Title is no static porperty as mentioned above and listed it as error.
So for at least the Model Binding there seem to be no oportunity for that if it is not Static or will it compile althought correctly because the generator of the codebehind is pushed only then?

2. Converters and the CommunityTookit

You are absolutly right by guiding to their documentation, so maybe let me specify my idea behind my post here:

We do have a guide to "How to use CommunityToolkit 8.x" and somewhere else also a "Converters" Topic in the Documentation.
The Toolkit Guide is telling about the imlementation of a Control section, where I did get the information from to add the package and that for using this, there is a minimum target version of windows needed. Not that there at least are samples of Converters are included

The Converters mentioned in Uno docs are only in the c# area and just telling that IValueConverter Interface is needed for that and giving implementation example how to use it in c# markup fitting to the area it is in.
But giving the actual code which is provided there:

Using a Converter
There may be times when you may want to simply use a converter instead of providing a delegate over and over. For these scenarios, you may want to provide some sort of static readonly context like:

public static class Converters
{
    public static readonly IValueConverter InverseBoolConverter = new InverseBoolConverter();
}

new Button()
    .Enabled(x => x.Binding(() => vm.IsBusy)
        .Converter(Converters.InverseBoolConverter));

I came to the result that this Converters Documentation should be clearer Marked as "WPF" section, because for non WPF using uno applications you would have to do this import:

using XCeed.WPF.Toolkit.Core;

but in a non WPF solution the question would be: Do we want to have a WPF import in a non-WPF Application? My Answer would be No.
So resulting of that, my Idea was to add a guide for how to implement the CommunityToolkit in a Uno application for example Xaml Code in a non WPF Application like I did.

So minimal effort way for adjustment could be:
If someone uses the searchbar with "Converters" and got ot the c# section, there could be a link in the "Using a Converter" for pointing towards the CommunityToolkit for non wpf applications, so there would be the way to go for having the whole way to go, not missing the maybe needed import and guide to use the toolkit in uno app before actually be able to use it without trouble.

On the WTK section I took a closer look and compared to the provided sample, there is missing a (for beginners who actually use tutorials and how to guides) section which tells the reader to do the Page:Ressources section.

If there would be someone who could cross read and do the formatting (and Links, because seems that github web is not good for links), I could write the (for me missing) parts and provide it in a PR.

Thanks for the update.

It do tell that Title is no static porperty as mentioned above and listed it as error.

Static properties are being addressed to some extents in #18695.

Do we want to have a WPF import in a non-WPF Application?

You cannot import code from WPF as is, you need to convert it to WinUI first.

Thats what I said, I would not want a wpf import in a non wpf application, so in my opinion for a not wpf application we would need at least mentioning in the documentation in the converters topic, that would lead the user of documentation e.g. to the CommunityToolkit import and their documentation, to know what is missing there.
At the moment with just telling the reader to use this code mentioned in the converters section top area, and not mentioning this, the compiler will tell that this element is not known and leave the user with the idea to import the (like you said correcltly: not useable/wanted) wpf namespace or create this missing element.

@jeromelaban and to the x:Bind:
I do not fully understand what this PR is saying to the mentioned problem, sorry.
You are telling "static properties are addressed" but (tell me if i am wrong) the properties like Title or Name, we have in the MainModel file, are not marked as static, instead as e.g.:

IState<string> Name

Which makes the compiler throw a error.

Using x:Bind for Binding to the TextBox.Text and a converter do work, but unlike in c# markup (my app uses navigation if thats relevant) I did not have the vm to bind that property or method to using x:Bind.

Tryed this code for e.g. Title Property:

.Text("{x:Bind local: MainModel.Title, Mode="OneWay"}")

And the error points to the .Title part there to be not static, what is correct, but I don't know how to change that, so the compiler is happy and Me using x:Bind instead of Binding for that. In the xaml I did not find the DataContext I have in c# markup

I'm sorry, I misunderstood that you were talking about C# Markup. x:Bind is a XAML feature, not a C# Markup feature.

Essentially, C# Markup generally does not need converters. It is only needed to call methods that do bindings (including conversion) without needing to go to IValueConverter.

no, I was not talking about c# markup, just compared the functionallity. In a c# app you do say vm.Title (that uses DataContext which is in a c# markup app set at the top of the page definition.
is there a common workflow for that?
if I am adding

public MainViewModel vm => (MainViewModel)DataContext;

The Project will not build anymore with the InitializeComponent issue and telling me that the Properties of e.g. Name and Title which the intellisense suggested to me for

x:Bind vm. //<-suggestion here after the dot

repo to that showing how i did the x:Bind:
https://github.com/DevTKSS/MyUnoXamlApp.git

if there could be a relation to not just "me making issue in coding" then actually InitializeComponent() issue I can link it there also.