Regarding the question of splitting area 1 across the backbone (area 0):
[area 1, subnet 1]---[ABR #1]---[area 0, subnet 2]---[ABR #2]---[area 1, subnet 3]
[area 1, subnet 1]---[Router #1]---[area 0, subnet 2, end device #1]---[Router #2]---[area 0, subnet 2, end device #2]---[Router #3]---[area 1, subnet 3]
Short answer: There is no problem with your proposal...
Long answer:
Even Peter's answer, which argues that reusing area numbers is bad design, offers no proof that this is a bad design; if you examine the hyperlinks he used, there is no explanation of undesirable consequences for this design. Furthermore, the argument that you might have problems connecting R1 and R3 falls short, since the R1 to R3 link could legitimately be configured in either Area 0 or Area 1, depending on what traffic you want to transit it. The difficulties he mentions are a false dilemma.
In RFC 2328, Section 3.7 OSPF explicitly allows you to use discontiguous non-backbone areas (which are called "area partitions", below):
OSPF does not actively attempt to repair area partitions. When
an area becomes partitioned, each component simply becomes a
separate area. The backbone then performs routing between the
new areas. Some destinations reachable via intra-area routing
before the partition will now require inter-area routing.
... Also, the backbone itself must not partition.
Thus whether you use the proposed discontiguous Area 1 is just a matter of taste... some people find it illogical to use the configuration in your diagram; these people might suggest that you keep OSPF area numbers together... so you'd have to change [area 1, subnet 3] on Router #3 to [area 3, subnet 3]. Other people see no problem with reusing Area 1, since OSPF area numbers are only locally significant to the router originating OSPF hellos.
Either way, we should admit that OSPF is a remarkably flexible protocol; regardless of choosing one side or another in this debate.
I have seen this before on other host types. Putting in default gateway addresses should prevent this behavior. Without a default gateway, the host sends an ARP for the other host's layer-3 address, and it receives a reply because the hosts are on the same layer-2 domain. With a default gateway, the host would ARP for the gateway's layer-3 address, not the other host's layer-3 address, but there is no gateway address for which to ARP.
Best Answer
That is the point of DHCP relays, so yes. DHCP relay takes the broadcasted DHCP discovery and converts it into a unicast packet destined to the DHCP server.
and
I think your question is not actually about DHCP relay. You are really asking why when your Cisco device is set as a router you don't have access to the Internet from the second subnet.
My question would be how does your Actiontec router know about the subnet behind the Cisco device? Does it support a dynamic routing protocol (and do you have it configured correctly on both devices)? Did you configure a static route?
Combining that statement with the piece of information that it works when the Cisco is operating as a gateway leads me to believe that the Actiontec device simply doesn't know where to send traffic destined to your second subnet.
When the Cisco device is a router, the Actiontec is only aware of the two directly connected subnets (WAN and LAN). Traffic for any other unknown subnet (like your second subnet) it sends to it's default route which would be upstream.
When the Cisco device is operating as a gateway, it is NATing traffic to an IP address on the first subnet. Since this would be local to the Actiontec, it can send the traffic along as expected.