That dock uses a DisplayLink chip.

A DisplayLink chip is essentially a tiny GPU that handles the final outputting to the display. When the DisplayLink chip is in use the laptop's GPU still does 99% of the work, but the DisplayLink chip handles the final outputting to the display.

This has the major advantage of allowing it to work with a much wider selection of devices (almost anything with a USB port and a DisplsyLink driver available), however the additional complexity and drivers can lead to some finicky behavior and artifacting. Overall I suggest avoiding DisplayLink docks unless you actually need the benefits.

For the Framework Laptop most Thunderbolt 3/4 and USB4 docks should work, but not all.

USB4 supports two different methods for a dock to run multiple monitors. The computer can send multiple separate display signals to the dock or the computer can send a single (higher bandwidth) display signal that the dock can then split into multiple display signals.

From the end user's perspective those are identical as long as they work, however AMD USB4 controllers (like the ones in the FW16) only work with the latter method (single display signal that is split) whereas MacOS works better with the first method.

Most USB4/Thunderbolt 3/4 docks use the method that works with AMD, however some docks that are marketd towards Mac users will not work. The most common docks that won't work are Caldigit docks.

If you want a docking station that works with either the Framework or a MacBook then that may be a good reason to use a DisplayLink dock.

Most modules I found do have XMP. Do they just mean to disable XMP? Any ideas or recommendations?

Many modules support higher speed with XMP than with JEDEC (the standard speed of the modules).

Their recommendation to avoid XMP modules is two-fold:

1. The laptop will not allow the module to run at XMP speeds, so customers shouldn't based their ram purchasing decisions on XMP specs.
2. With the DDR4 Framework laptops there was an issue where some ram modules with XMP support, particularly from Kingston, would have issues falling back to JEDEC speeds and struggle to boot.

With DDR5 however a lot of RAM brands have started supporting both XMP and JEDEC even if XMP isn't any faster than JEDEC on the modules. This is to bypass any motherboard limits on how fast the ram is allowed to run. This is common enough that I hope this won't cause issues with Framework (ie. Hopefully reason 2 is resolved) and since the XMP and JEDEC are both fast reason 1 doesn't apply.

I'm also hesitant to buy the 180W charger, even though it seems reasonalibly priced. I'm not buying a grafics module just yet, but might in the future and 180W might not be enough power by then. I only want to buy once and couldn't find any higher powered ones on amazon (EU). I only found one 140W charger from UGREEN, which is a brand I've never heard of. Another option would be, to buy a 100W charger now and another one later, but I want to reduce cost and e-waste.

The open standard for USB-C at greater than 100w is pretty new. The few products so far that do support it have been limited to 140w. Framework's charger is the first to go above 140w on the new standard.

UGREEN is a common and reputable brand. After Anker's scandal (major scandal involving their security cameras) UGREEN is now my go-to brand for chargers. I also like Satechi (as they aren't a Chinese company like UGREEN) however they are usually overpriced.

One last question is concerning the input modules. Do I understand it correctly, that both the numpad as well as the macro pad can be used for custom key functions and macros?

IIRC all of them are fully programmable using QMK/VIA.

Depends.

For gaming (even light gaming) I'd pick the 5600 MT/s option. This is because the iGPU shares memory with the CPU, and iGPUs are very bandwidth hungry.

However for average day-to-day use memory bandwidth is less important as long as it's good enough (and 4800 MT/s is plenty), so for that I'd pick having more memory.

32GB 4800 MT/s costing about the same as 16 GB 5600 MT/s is odd. Quickly looking at prices here in the US the 32 GB is around 60% more expensive.

Framework has released schematics on GitHub for a card to allow for installing two additional M.2 drives in the expansion bay shell. IIRC they've hinted about plans to put that into production later this year.

I'm holding out in case they make a 16:9 version sometime. I watch a lot of streaming / YouTube and it would bug me because I don't think I've ever watched 16:10 content.

I doubt they will.

A normal keyboard with a numpad beside it and a decent sized trackpad beneath it happens to work out to an approximately 16:10 aspect ratio, which is why the Framework 16 uses a 16:10 display.

Similarly a normal keyboard (no numpad) and a decent sized trackpad beneath it is approximately a 3:2 aspect ratio, which is why the Framework 13 uses a 3:2 display.

Using a wider aspect ratio such as 16:9 results in either wasted space above/below the display, wasted space on either side of the keyboard, or a small trackpad. All of those can be annoying. This is why a lot of premium laptops use taller aspect ratios.

It would be nice if Framework did offer an option to get a 16:9 display, however as Framework has said they have a lot of different customers wanting lot of different parts options, and trying to create all the different parts that different people want would be a nightmare of logistics for Framework to keep in stock and available. So Framework has to pick and choose what is actually worth creating.

I doubt it is worth the effort for Framework to stock a 10% smaller display, bezels to go with that display, laptops equipped with those displays (since the display is one of the parts that is pre-installed on all laptops) just for the customers that want larger bezels and less usable screen space because it gives a better 16:9 content viewing experience.

IPv6 clients can communicate with IPv6 servers.

IPv4 clients can communicate with IPv4 servers.

In order to mix and match you need some intermediary server that has both IPv4 and IPv6 to translate.

For example my mobile service provider (T-Mobile US) doesn't support IPv4 on their network, however I can still access IPv4 services because they automatically route that traffic through a NAT64 server, which translates the IPv6 from my device into IPv4 heading to the IPv4-only service.

T-Mobile actually takes it a step further than many other IPv6-only service providers. NAT64 alone only solves problems with servers that are IPv4-only, whereas T-Mobile uses 464xlat (which includes NAT64) which also solves problems with apps on the user's device that are IPv4-only.