Sort of a backwards comparison of InfoPath and XAML shows up here: XSLT in the .NET Framework: Data Binding and Control Creation at the Same Time. My comment is below.

XAML is a lot of things. Including being able to create a form-like experience. As I mention below, I can appreciate the frustration developers sometime have figuring out all the Microsoft overlapping technologies and which are the most appropriate for their situation. Sometimes InfoPath. Sometimes not InfoPath.

InfoPath is not going to be replaced by XAML. But you might see people using XAML technology for form-filling applications. And that's okay. And hopefully appropriate.

Comment:

Disclosure: I work on InfoPath.

InfoPath is by no means a stop-gap measure awaiting XAML. In some ways, it's too bad that Microsoft has so many different technologies for doing similar things (e.g., forms) but it's better than coming up with the uber-form package that probably is so complicated and full of comprises that it pleases no one.

InfoPath is super-appropriate for the Enterprise environment, especially for people already with the Office Pro Enterprise license. It's in there.

With Office 2007, we have the Forms Server for filling out forms in IE or Firefox. And the InfoPath rich-client control is now hostable (yay COM!) showing up in more and more products like Word, Excel, and PowerPoint. And we have a fantastic Outlook integration story.

XAML and Office? That's not on my radar. But right now I'm focused on getting InfoPath 2007 wrapped up, polished, and exploding out of the door.