I think the main obstacle stems from handling the whole logic starting from the final perimeter of the polygon 
because your angles are always 90 degrees, and because your polygon is closed, if you represent its edges with vectors starting from a random corner, proceeding clockwise/countercloskwise, you end up with something like this:
in my mind, approaching this problem “outside → in” (starting from the perimeter and getting its edges) is infinitely more difficult than approaching it inside → out (starting from the edges and getting its perimeter)
the final perimeter is just the mass addition of the length of all the edges, but all the edges must “be able to exist” before being counted in the perimeter: for an edge to exist, it must be multiple of “brick length”
not all perimeters can exist by following this rule: bricks must always be even, you add two or you remove two because the polygon must be closed, so you perimeter will increase/decrease by a minimum of (2 * BrickLength)
if brick length = 5, you will always end up with a closed polygon with 90° angles with perimeter value multiple of 10
you can chose the approximation of the edge length transformed into bricks by using the math you prefere
here is by using integer division, so the perimeter made of bricks will always be equal or smaller (even much smaller) than the “plain scaled” perimeter
or you can use something like Round → Ceiling to always get a higher result
or Round → Nearest (this also has the right color preview as in your sketch)
Polygon_in_Bricks.gh (23.6 KB)
