heaptrc 에러는 예전부터 32비트 버전도 가지고 있었고 32비트 daily snapshot 버전도 동일증상입니다.
아무래도 완성도면에서는 델파이에 많이 떨어지는 편인 것 같습니다.
프리파스칼의 최적화 성능도 그렇고(델파이보다 50%이상 느리다고?) 런타임라이브러리(RTL,FCL)의 유니코드 지원이슈도 그렇고
LCL(VCL클론?) 의 성능도 그렇고 델파이이에 비하면 많이 부족하죠.

그래도, 라이센스 걱정없이 쓸 수 있다는게 최대 장점인 것 같습니다.
특히, 회사내에서  작은 크기의 단일실행파일 WIN32 GUI 유틸리티를 만들때는 이만한게 없는 것 같습니다. ^_^;;
현재 제가 만든 몇가지 프로그램들이 회사내에서 유용하게 쓰이고 있습니다.

점점 더 나아지겠죠~~
7~8년전 처음 봤을 때는 IDE 자체에러가 꽤 많아서 프로그래밍 자체를 하기조차 힘들었거든요.~

빌더(TWx) 님이 쓰신 글 :
:
:
: Heap 관련해서 버그가 없나 확인해보기 위해 라자루스를 트레이싱 모드로 컴파일 해봤는데 위와 같은 문제를 보이네요.
:
: Heap 관련 Diagnostics는 FPC 컴파일러 소스 중에서 관련 유닛이 처리하고 있고...
:
: 전체 소스를 다 뜯어 보지는 않았지만 라자루스 RTL에 뭔가 문제가 있는 것으로 보입니다.
:
:
: 파일오픈 다이얼로그 관련해서는...
:
: Windows 8 64 bit 버전 OS 에서도 같은 증상을 보였는데...
:
:

: unit Unit1;
: 
: {$mode objfpc}{$H+}
: 
: interface
: 
: uses
:   Classes, SysUtils, FileUtil, Forms, Controls, Graphics, StdCtrls,
:   shlobj, ActiveX;
: 
: type
: 
:   { TForm1 }
: 
:   TForm1 = class(TForm)
:     Button1: TButton;
:     procedure Button1Click(Sender: TObject);
:   private
:     { private declarations }
:   public
:     { public declarations }
:   end;
: 
: var
:   Form1: TForm1;
: 
: implementation
: 
: {$R *.lfm}
: 
: { TForm1 }
: 
: procedure TForm1.Button1Click(Sender: TObject);
: var
:    Dialog:    IFileOpenDialog;
:    retValue:  HRESULT;
: begin
:   retValue := CoCreateInstance(CLSID_FileOpenDialog, nil, CLSCTX_INPROC_SERVER, IFileOpenDialog, Dialog);
:   if (retValue = S_OK ) and Assigned(Dialog) then
:   begin
:      Dialog.Show(0);
:   end;
: end;
: 
: 
: end.
: 

:
:
: 컴포넌트를 사용하지 않고, 위와 같이 COM 객체를 직접 생성하고 난 이후 부터는 문제의 증상이 사라졌고요.
:
: 여러 상황으로 미루어 볼 때.. 사용하는 운영체제의 문제라기 보단.. 라자루스 자체가 문제를 갖고 있는 것으로 보이네요.
:
:
: ...