> I was under the impression that bsf and  bcf instructions are OK on a
> Port as long as the I/O directions are not changed.

This is mostly true, but with two more exceptions:

[1] On port RA4, even if you are "outputting" a one, in the absense of an
    external pullup or in the presense of an external pulldown, the port
    will read low and consequently any bit operation elsewhere on port A
    will clear RA4; this can be a particular "gotcha" when doing I2C-style
    communications since dropping the clock wire following the acknowlege
    will cause the remote device to de-assert the data wire but since the
    data wire was asserted at the time clock changed, the RA4 latch will
    most likely continue to assert RA4.

[2] If any other port is held at a value other than its programmed value,
    it will change to that value.  Usually ports (other than RA4) will not
    be held at any level other than what they're programmed for, since that
    would require sinking/sourcing excessive current through the PIC.  How-
    ever, there may be some cases where this overcurrent occurs as a tran-
    sient condition (either systemically or 'randomly') and must be dealt
    with.

    Common example #1: Driving a capacitive load

    If the PIC is driving a capacitive load, a change to a port pin's prog-
    rammed value may not cause the output to swing "instantly".  Since there
    is only one CLOCK cycle (not instruction cycle) between the the "write"
    part of one instruction and the "read" part of the next, a port which is
    loaded even moderately may be unable to "swing" fast enough to properly
    handle two consecutive BSF's/BCF's of different bits.

    For example, if a port's peak current-sourcing ability is 100mA, then a
    0.01uF cap will charge 10 volts per microsecond; in the 250ns between
    a write and the following read, however, it will only have time to charge
    2.5 volts and the port pin may not switch.  Capacitance less than 0.01uF
    shouldn't pose a problem at 4MHz, but at 20MHz any capacitance above about
    0.002uF may cause the same problem behavior.

    To avoid being bitten by this, follow Microchip's advice and avoid using
    consecutive BSF/BCF instructions on different bits of the same port.  If
    possible, rearrange your code so that you can put a "useful" instruction
    between the BSF/BCF.  If this is not possible, use a "nop".  Note, how-
    ever, that using a consecutive BSF/BCF on the SAME BIT of the port does
    not pose a problem.

    Common example #2: driving a bus

    If the PIC is sharing some signals with another CPU in a bus arrangement
    and the signals are sometimes used for output and sometimes for input,
    care must be taken both to ensure that bus conflicts are avoided since
    two PIC port pins "fighting" each other may pass enough current to damage
    one or both devices.  In general, any properly-designed and properly-func-
    tioning scheme should have no time, ever, where both PICs try to output
    conflicting values.  Nonetheless, "the best laid plans of mice and men
    aft go aglee" and it's necessary to minimize the effects of malfunctions.

    In general, the best way to avoid having port bins get changed awry in
    this type of situation is to put a small resistor (100ohms or thereabouts)
    between the PIC and the bus.  This will limit the peak currents in case of
    conflict to something reasonable (5v/200ohms = 25mA) while also ensuring
    that each PIC sees the output level that it's trying to put on the bus.

In general, the PIC's way of handling the BSF/BCF instructions works fine.
The traps where it does not, however, must be avoided.  Fortunately, the use
of simple design practices in hardware and coding makes such avoidance easy.