Hi Mohamed,
The contradiction you note was from my initial reading of the new feature which my post indicated as such, "bleeding edge" was my phrase I see :-) Unfortunately, this feature on parse only applies to multipart/related attachments, not multipart/form-data. The parse policy for form-data will keep the payload as a buffer in context.message.body. There will be no attachments as there are with multipart/related. I would suggest that you open a request for enhancement for handling of form-data by the parse policy as it would definitely be easier if the parsing of each part of the form data were done for you by the parse policy.
Given this behavior, what specifically are you attempting to do with your form-data? What I've had to do is to use GatewayScript to do a context.message.body.readAsBuffer function, get the boundary attribute from the content-type header (which the parse policy may have moved into message.original.headers.content-type) and use the buffer.indexOf function to find the start and end of each part to parse out the different parts of the form-data based upon the boundary string. A simple matter of programming for sure but it would be nice if something was done for you automatically as it is for related requests.
Best Regards,
Steve Linn