Mikrotik uses VLAN ID 1 as synonym for untagged

This is, fortunately or unfortunately, not true. I used to think the same until I've found out that it is not VLAN ID 1 which is always handled untagged but it's actually "the VLAN ID which is configured as bridge's own pvid parameter" which is treated as untagged on the bridge. If you change bridge's own pvid to something else than 1, VID 1 starts behaving normally.

Perhaps things slightly changed with event of bridge vlan-filtering ... in previous times, when bridge was sort of a dumb switch, bridge interface happily utilized packets belonging to VLAN ID 1 just the same as explicitly untagged while one had to use VLAN interface for the rest of VLANs. This might explain why pvid=1 is default setting ... to keep (broken) bridge port behaviour the same as it was before 6.42.
I guess this is the origin of @sindy's explanation about what happens on the bridge.

But then again, setting bridge's pvid to some other value and setting member interfaces' pvid to the same value re-instate the same behaviour ... seemingly untagged packets on bridge, but my own simplification covers that variant just the same.

Anyhow, I'll stop bitching about this ... it is one view vs. another one and unless some MT developer explains the way it's really implemented in ROS it's all just guessing.

/interface bridge port
add bridge=bridgeHallway comment=defconf interface=ether1 (pvid=1)
add bridge=bridgeHallway comment=defconf interface=DevicesHallway pvid=45

/ip bridge vlan
bridge=homebridge untagged=ether1 vlanid=1 is correct as it is consistent with the other interfaces

But what does that mean.......... Will the CapAC remove vlanID1 from packets going to the WLAN?? and the packets will have vlanid0 and if so how will that affect devices connecting??
As you can surmize I am still not sure how to handle the bridge vlan for my capAC for ether1

There's a distinction between untagged frame and frame tagged with VLAN ID=1. The former has ethertype value 0x0800 (or, if it's not about IPv4 packet, appropriate ethertype value), the later has (outer) ether type 0x8100 with additional header (3 bits PCP - priority code point; 1 bit DEI - drop eligible indicator and 12 bits VID with value of 1 in this particular case) followed by usual ethertype 0x0800 (or, if it's not IPv4 packet, appropriate ethertype value).
So in the latter case, receiver would have to know how to deal with 802.1q frames (or blindly strip them which would become a problem in the other direction if switch/router actually expected 802.1q frames with VID set to 1) while in the former case it really is about truly untagged, plain ethernet.

In the quoted case cAPs really should strip VLAN headers even with VID=1 not to confuse wireless clients.

Okay so then would this make sense for my capACs.....
/ip bridge vlan
bridge=bridge tagged=eth1 untagged=guest-wifi vlanid=200
bridge=bridge tagged=eth1 untagged=smart-devices vlanid=45
bridge=bridge tagged=eth1 untagged=homeuser-wifi vlanid=1

and because the previous post stated that vlan1 is untagged by default on the bridge we dont need the following as well
bridge=bridge untagged=eth1 vlanid=1 ???

In other words I dont know what to do with trunk port eth1 and vlan1 ????

The discussion with @sindy was, AFAIK, debate only about how bridge (port and something-like-a-switch) behaves. Now you have your dilemma about ether1 ...

With the first block of settings you're saying that ether1 should be tagged member of VID=1, thus frames, traveling on the wire, should have VLAN tags with VID=1.
With the second block, you're changing that to the state where frames, traveling on the wire, should be untagged when frame belongs to VID=1 inside cAP.

Regardless of VLAN ID (VID=1 should be considered just the same as other VIDs when on ethernet wire) settings should be consistent on both sides of wire. So setting on cAP should mirror those on router/switch/... (I don't know which device is on the other end of that UTP cable).
If you want to be consistent about VIDs on all of your LAN infrastructure devices, you should stick to all tagged trunks ... because it's just too easy to set port pvid on one end to something and on other end to something else. If frames traveled between those two ports tagged, you'd spot such error quite easily (VLAN wouldn't work).

As to how's VID=1 dealt with by default on bridge ... I'm all frustrated and I'll repeat once more (and then shut up forever): don't ever use VID=1 in any setup and always have frames tagged in LAN infrastructure ... untagged should only live on access points (wires outside active LAN infrastructure perimeter and wireless SSIDs). I'm sticking to these rules and I don't have any problems whatsoever (neither conceptual nor real).

don't ever use VID=1 in any setup and always have frames tagged in LAN infrastructure ... untagged should only live on access points (wires outside active LAN infrastructure perimeter and wireless SSIDs). I'm sticking to these rules and I don't have any problems whatsoever (neither conceptual nor real)..

100% agree.

Okay so I will create a VLAN for my homelan which DOES NOT sit on vlan1 so to speak and thus will not be in this quandry LOL.
Thanks! Consistent also with pcunite using vlan10 for his MAIN LAN.

Okay, now Im stuck. I want to use vlan11 instead of 1, but the problem I am having is that
pcunite has bridge set to pvid=1

I want my bridge lan to be vlan 11

In other words his example now brings me to MKXs point is that default is far too confusing and we should avoid using vlan1 for everything.....
SO asking pcunite to use vlan=10 for his bridge so that it matches up with the NORMAL MAIN LAN of his examples!!!!!