So, I've battled with this quite a bit lately and discovered it is indeed possible to match curl functionality, but it's not immediately obvious how to do multipart/form-data correctly. All the responses above have covered important pieces of the puzzle, but I'm going to try and tie it all together here for the next sorry fellow who is trying to implement curl functionality in native Powershell.
@jklemmack's solution is the one that put me on the right track, and is the most flexible, because it allows you to construct the form-data content specifically, controlling both the boundaries, along with how the data gets formatted within it.
For anyone trying to do this, I think it's important that you arm yourself with a proper web debugging proxy like Fiddler (.net) or Burp Suite (java), so that you can inspect each of the REST calls in detail to understand the specific format of the data being passed across to the API.
In my specific case, I noticed that curl was inserting a blank line above each part of the form data - so to extend @jklemmack's example, it would look like the following:
$bodyLines = (
"--$boundary",
"Content-Disposition: form-data; name=`"formfield1`"",
'',
$formdata1,
"--$boundary",
"Content-Disposition: form-data; name=`"formfield2`"",
'',
$formdata2,
"--$boundary",
"Content-Disposition: form-data; name=`"formfield3`"; filename=`"$name_of_file_being_uploaded`"",
"Content-Type: application/json",
'',
$content_of_file_being_uploaded,
"--$boundary--"
) -join $LF
Hope this saves someone a lot of time in the future!
I also still agree that if you need to do this from scratch, and have the option of using the curl native binary directly (while ensuring due-diligence around security and compliance), that you take advantage of it's maturity and the conveniences that it provides. Use curl. It is better that this multipart logic be vigourously tested and maintained by the curl community at large, vs the onus being on your internal dev or operations teams.