XAML is an XML-based declarative markup language suitable for representing nested object hierarchies, such as those of CLR objects. This makes it a good choice for building user interfaces (which are inherently nested and hierachical). This is how Windows Presentation Foundation employs XAML. Windows Workflow on the other hand employs XAML to orchestrate workflows.

Windows Forms was built as a managed wrapper over Win32, and is as such limited by what Win32 can do. XAML when used in WPF works to achieve the same goal: building user interfaces on Windows. But WPF was developed from the ground up to be Microsoft's next-generation presentation subsystem -- with a new composition system, uniform programming model for documents, graphics, effects, animation and UI. WPF is currently not a replacement for WinForms. You will find that there are some things that WinForms does exceptionally well, and others that WPF excels in. Besides, there is good interoperability between these two technologies, so your solutions can potentially use the best of both worlds.

I would like to add a few comments to what Ashish has elaborated. Because XAML is an XML syntax, it lends itself to being edited outside of a development environment. The entry bar for creating a designer for WPF UIs is much lower than that for Winforms because of this.

Even further, you can mock up a WPF UI using nothing more than Notepad (similar to how I can mock up an HTML page with notepad) and that mockup is immediately useful, without modification to a developer.

Microsoft is emphasizing this feature of XAML with the Expression Interactive Designer, showing how a graphic designer can create a UI -- using tools targeted for a graphic designer -- for a developer and the developer can use those same files -- in Visual Studio -- to code the logic that drives the UI.

In addition, I'm sure just as there is a market for WYSIWYG HTML designers, once XAML takes off we will see a good deal of WYSIWYG XAML designers.

As a final note, there is nothing to stop another platform from implementing a XAML interpreter...although this is the least likely scenario to occur.

Okay one more thing really this time. Although as Ashish points out WPF doesn't excel at everything that Winforms handles well, I think what's lacking right now is basically some of the controls. I'm looking forward to the second release to address that issue. Can someone say Orcas? Where it is lacking against Winforms can be supplemented by custom controls (by yourself or a third party). And where it surpasses Winforms...it really REALLY knocks it out the box.

In summary, short-term I think WPF/XAML is more of a niche/early-adopter tool. In the long-term, I'm pretty sure it is the successor of winforms. How many developers do you know code in MFC today?